DHCP e configuração automática de rede

Conectar o cabo não completa a configuração

Um dispositivo pode detectar o Wi‑Fi ou o enlace Ethernet e ainda não saber como se comunicar além daquele meio. Para participar de uma rede IPv4, ele normalmente precisa de um conjunto coerente de parâmetros:

• um endereço IP utilizável naquela sub-rede;
• uma máscara ou comprimento de prefixo;
• um ou mais roteadores para destinos externos;
• servidores DNS para resolver nomes;
• tempos e outras opções definidos pela rede.

Configurar tudo manualmente em cada notebook, celular ou máquina virtual seria lento e sujeito a duplicidades. O Dynamic Host Configuration Protocol, ou DHCP, permite que a rede entregue parâmetros de maneira administrada e, quando necessário, temporária.

DHCP não “cria Internet” nem testa se um site está acessível. Ele fornece configuração. A comunicação posterior ainda depende de enlace, endereçamento, roteamento, DNS, políticas e serviços funcionando.

Endereço, prefixo, gateway e DNS cumprem papéis diferentes

Considere uma configuração IPv4 recebida por um notebook:

Endereço: 192.0.2.34
Máscara: 255.255.255.0
Roteador: 192.0.2.1
DNS: 198.51.100.53
Concessão: 8 horas

Cada linha responde a uma pergunta:

O servidor pode entregar outros parâmetros, conforme opções padronizadas e política local. Receber apenas um endereço não garante que a configuração esteja completa; uma máscara errada, um roteador inalcançável ou um DNS inválido produz sintomas diferentes.

A estrutura e os escopos do endereço estão detalhados em Endereçamento IPv4. Aqui o foco é como o conjunto chega ao host e permanece válido.

Cliente, servidor e relay dividem o trabalho

A arquitetura possui três papéis principais:

• cliente: solicita parâmetros para uma interface;
• servidor: escolhe configuração segundo pools, reservas e políticas;
• relay agent: recebe mensagens no enlace do cliente e as encaminha quando o servidor está em outra sub-rede.

O servidor mantém informações chamadas de bindings, que relacionam cliente, endereço, tempos e estado. Isso permite controlar concessões sem instalar um servidor em cada domínio de broadcast.

O cliente não precisa conhecer o endereço do servidor na primeira inicialização. É justamente esse desconhecimento que leva à descoberta local.

DHCPv4 começa antes de o cliente possuir IPv4

DHCPv4 usa UDP. O servidor recebe normalmente na porta 67 e o cliente na porta 68. Um cliente sem endereço pode enviar de 0.0.0.0 para o broadcast limitado 255.255.255.255, além de marcar informações no formato herdado de BOOTP.

Broadcast é importante porque o dispositivo ainda não sabe:

• qual endereço poderá usar;
• onde o servidor está;
• qual roteador alcançaria outras redes;
• se existe mais de um servidor capaz de responder.

O cliente gera um identificador de transação, xid, para relacionar respostas à solicitação em andamento. Mensagens de outra transação não devem ser aceitas como se pertencessem ao fluxo atual.

Um endereço de hardware pode aparecer no campo apropriado, e uma opção de client identifier pode identificar o cliente. Porém, “cliente DHCP é sempre a MAC” é uma simplificação incorreta. O identificador pode seguir outros formatos, e máquinas virtuais, privacidade, múltiplas interfaces e implementações modernas tornam perigoso usar somente a aparência de uma MAC como identidade universal.

Descoberta, oferta, pedido e confirmação formam o fluxo conhecido como DORA

Uma alocação nova costuma ser ensinada por quatro mensagens:

1. DHCPDISCOVER: o cliente procura servidores;
2. DHCPOFFER: um ou mais servidores oferecem endereço, concessão e opções;
3. DHCPREQUEST: o cliente indica a oferta escolhida;
4. DHCPACK: o servidor confirma a configuração.

As iniciais formam DORA. É um bom mapa para a primeira concessão, não uma descrição de todo pacote DHCP. Renovação, reinicialização com endereço conhecido, consulta apenas de parâmetros e erros seguem fluxos diferentes.

O cliente pode receber várias ofertas e escolhe conforme sua implementação. “A primeira sempre vence” não é uma regra do protocolo. A oferta contém um server identifier; ao enviar o pedido da fase de seleção, o cliente inclui o servidor escolhido e o endereço solicitado.

O broadcast do DHCPREQUEST permite que outros servidores associem a decisão à transação e liberem o que haviam reservado temporariamente. O servidor selecionado responde com DHCPACK se puder confirmar. A forma exata de entrega da resposta — broadcast, unicast ou por relay — depende do estado e dos campos da mensagem.

Opções tornam o DHCP extensível

O endereço oferecido aparece em campos da mensagem, enquanto muitos parâmetros viajam como opções. Entre as opções DHCPv4 conhecidas estão:

O cliente pode enviar uma lista de parâmetros solicitados. Isso não obriga o servidor a fornecer tudo: disponibilidade, política e compatibilidade influenciam a resposta.

Opção também não significa que o cliente usará o valor cegamente. A implementação verifica formato, estado da transação e regras locais. Opções desconhecidas podem ser ignoradas conforme a especificação aplicável, preservando extensibilidade.

DHCPACK confirma a concessão, mas o cliente ainda verifica o ambiente

Depois do DHCPACK, o cliente registra parâmetros e tempos. Em redes com ARP, ele deve verificar se o endereço sugerido já parece estar em uso antes de adotá-lo plenamente.

Se detectar conflito, pode enviar DHCPDECLINE e reiniciar a obtenção. O servidor marca ou investiga o endereço de acordo com sua política. Essa verificação reduz conflitos, mas não transforma DHCP em um sistema infalível de inventário.

Outras mensagens importantes incluem:

• DHCPNAK: o servidor informa que a configuração solicitada não é válida naquele contexto;
• DHCPRELEASE: o cliente avisa ao servidor que não precisa mais da concessão;
• DHCPINFORM: um cliente que já possui endereço solicita outros parâmetros sem pedir nova concessão.

DHCPRELEASE é útil, mas não pode ser a única forma de recuperar endereços: dispositivos desligam abruptamente e saem de alcance. O prazo da concessão existe para que o servidor volte a administrar endereços mesmo sem uma despedida limpa.

Concessão não transfere a propriedade do endereço

Uma lease, ou concessão, autoriza o cliente a usar um endereço durante um intervalo. O servidor compromete-se a não realocar aquele endereço de modo incompatível enquanto a concessão estiver válida.

Três momentos organizam o ciclo DHCPv4:

• T1: cliente entra em RENEWING e tenta renovar com o servidor que concedeu o endereço;
• T2: sem sucesso, entra em REBINDING e tenta alcançar qualquer servidor capaz de renovar;
• expiração: sem DHCPACK válido, deve parar de usar o endereço da concessão.

O servidor pode fornecer T1 e T2. Quando não fornece, a RFC 2131 define valores padrão de 50% e 87,5% da duração, respectivamente, com variação para evitar que muitos clientes renovem ao mesmo tempo.

Se o servidor confirma a renovação, os tempos são recalculados e o estado retorna a BOUND. Se envia DHCPNAK, o cliente precisa abandonar a configuração e reiniciar conforme o estado aplicável.

Um equipamento que reinicia pode tentar confirmar um endereço usado anteriormente por DHCPREQUEST, no estado INIT‑REBOOT, em vez de começar necessariamente com uma nova descoberta completa. O servidor avalia se o endereço ainda é adequado à rede atual.

Reserva no servidor não é o mesmo que endereço manual

Uma reserva DHCP é uma regra administrativa para oferecer determinado endereço a um identificador de cliente. O host continua usando DHCP e recebe opções, concessão e atualizações pelo protocolo.

Um endereço manual é configurado localmente no host sem depender da concessão. Se for escolhido dentro de um pool sem coordenação, o servidor pode oferecê-lo a outro cliente e criar conflito.

Boas práticas administrativas separam ou coordenam:

• intervalos dinâmicos;
• reservas;
• endereços manuais;
• exclusões e endereços de infraestrutura;
• tempo de concessão adequado à rotatividade da rede.

Reserva também não é autenticação forte. Conhecer ou imitar um identificador pode ser possível. Controle de acesso precisa de mecanismos próprios.

Relay conecta o broadcast local a um servidor distante

Roteadores não encaminham broadcasts IPv4 locais como tráfego comum. Se o servidor DHCP está em outra sub-rede, um relay agent escuta as mensagens na interface do cliente e encaminha a solicitação ao servidor, normalmente por unicast.

O relay inclui informação sobre a rede de origem, como giaddr, para que o servidor saiba de qual pool selecionar a configuração. O servidor responde ao relay, que entrega a mensagem no enlace do cliente conforme os campos e flags do protocolo.

A opção de informação do relay, conhecida como Option 82, pode transportar subopções como identificação de circuito ou ponto remoto. O servidor pode usá-las em políticas, mas deve confiar apenas em relays autorizados e tratar corretamente mensagens que chegam de interfaces não confiáveis.

Quando uma sub-rede não recebe ofertas, é comum o servidor estar saudável e o problema estar no relay, na interface associada, na rota de retorno, no filtro UDP ou no pool daquela rede.

DHCPv6 não é DHCPv4 com endereços maiores

DHCPv6 compartilha o modelo cliente-servidor-relay, mas usa mensagens, portas e estruturas próprias. A especificação vigente é a RFC 9915, publicada como STD 102 e substituta da RFC 8415.

Uma troca comum usa:

1. Solicit: cliente procura servidores;
2. Advertise: servidores anunciam disponibilidade;
3. Request: cliente solicita configuração ao escolhido;
4. Reply: servidor retorna o resultado.

Clientes DHCPv6 usam UDP 546; servidores e relays usam UDP 547. IPv6 já fornece endereço link-local e multicast, então a descoberta não copia o broadcast 255.255.255.255 do DHCPv4.

DHCPv6 pode operar de formas diferentes:

• atribuição stateful de endereços, normalmente por associações como IA_NA;
• delegação de prefixos a roteadores, por IA_PD;
• entrega de informações sem atribuir endereço, por Information-request;
• coexistência com endereços formados por SLAAC.

A relação entre link-local, Router Advertisement, SLAAC e DAD está em Endereçamento IPv6. Nesta aula, a diferença essencial é que a administração IPv6 pode combinar mecanismos em vez de escolher uma cópia direta do modelo IPv4.

Ausência de DHCP pode resultar em IPv4 link-local

Alguns sistemas, quando não obtêm IPv4 por outros meios, podem selecionar um endereço do bloco 169.254.0.0/16 segundo IPv4 Link-Local e verificar conflitos. Esse endereço permite comunicação limitada no mesmo enlace.

Ele não prova que o DHCP “entregou um endereço 169.254”. Também não fornece, por si, roteador para a Internet. Ver um endereço link-local em um cliente que esperava DHCP é uma pista de que a negociação não foi concluída, embora a causa ainda precise ser investigada.

No IPv6, possuir um endereço link-local é comportamento normal e necessário a vários mecanismos. Não aplique a interpretação de falha do IPv4 link-local automaticamente ao fe80::/10.

DHCP depende de confiança no enlace e na administração

Uma resposta aparentemente válida pode fornecer roteador ou DNS malicioso. Um servidor não autorizado também pode causar indisponibilidade com parâmetros errados. Do outro lado, solicitações em massa podem consumir pools e recursos.

A RFC 3118 define autenticação para mensagens DHCP, mas a segurança de uma implantação não deve ser presumida apenas porque existe uma especificação. Redes gerenciadas combinam controles como:

• permitir respostas de servidor somente em pontos confiáveis;
• validar bindings e origem em equipamentos de acesso;
• proteger a comunicação entre relay e servidor;
• monitorar mudanças, ofertas inesperadas e esgotamento de pools;
• separar redes e aplicar políticas de acesso após a configuração;
• evitar opções excessivas que revelem informação desnecessária.

Mecanismos chamados DHCP snooping podem criar uma fronteira entre portas confiáveis e não confiáveis e registrar relações observadas. O nome e a configuração variam entre plataformas; o princípio é impedir que qualquer dispositivo de usuário se comporte livremente como servidor.

DHCP também não autentica a pessoa por possuir uma concessão. O binding ajuda operação e auditoria, mas identidade, autorização e segurança do endpoint exigem evidências adicionais.

Diagnostique a negociação por etapa

Quando um cliente não recebe configuração, localize onde o fluxo para:

1. confirme que a interface está ativa e associada ao enlace correto;
2. capture a tentativa desde DHCPDISCOVER ou o estado de renovação atual;
3. verifique portas UDP, xid, client identifier e flags;
4. confirme se a mensagem alcança o relay da sub-rede;
5. observe se o relay encaminha ao endereço correto do servidor;
6. confirme que existe pool correspondente à rede de origem e endereços livres;
7. procure DHCPOFFER e veja se ela retorna pelo mesmo relay;
8. confirme qual oferta o cliente seleciona no DHCPREQUEST;
9. analise DHCPACK, DHCPNAK ou ausência de resposta;
10. valide conflito, máscara, roteador, DNS e tempos aplicados no host.

Os sintomas ajudam a restringir hipóteses:

Uma captura feita no servidor não mostra necessariamente o broadcast original: ela pode mostrar a mensagem reconstruída pelo relay. Compare os campos e capture em mais de um ponto quando precisar separar enlace local, encaminhamento e retorno.

Erros comuns sobre DHCP

• “DHCP entrega apenas IP”: ele pode fornecer máscara, roteadores, DNS, tempos e muitas outras opções;
• “DORA acontece em toda renovação”: um cliente já vinculado normalmente usa DHCPREQUEST e DHCPACK;
• “OFFER já autoriza o endereço”: a confirmação e o estado da transação ainda importam;
• “a primeira oferta sempre vence”: a escolha pertence à implementação do cliente;
• “MAC é sempre o identificador”: client identifier pode usar outras estruturas;
• “reserva é IP estático”: a reserva continua sendo administrada e entregue por DHCP;
• “broadcast atravessa o roteador”: relay recebe localmente e encaminha outra mensagem;
• “um ACK garante Internet”: ele confirma parâmetros, não DNS, rotas, filtros ou serviços externos;
• “169.254 veio do DHCP”: IPv4 link-local é um mecanismo separado;
• “DHCPv6 fornece gateway”: Router Advertisement informa o roteador padrão;
• “SLAAC e DHCPv6 não coexistem”: a rede pode combinar atribuição e informação conforme política;
• “concessão identifica a pessoa”: ela relaciona estado técnico, não prova identidade humana;
• “servidor DHCP é confiável por responder rápido”: origem e autorização precisam de controles próprios.

O que você deve guardar

DHCP distribui um conjunto coerente de parâmetros e administra o uso temporário de endereços. Na primeira obtenção DHCPv4, descoberta, oferta, pedido e confirmação formam o fluxo didático DORA. Opções carregam máscara, roteador, DNS, duração e outros valores.

Uma concessão possui ciclo de vida. T1 tenta renovar com o servidor original; T2 amplia a busca; a expiração encerra o uso autorizado se nenhuma confirmação chegar. Reserva no servidor e endereço manual no host são escolhas operacionais diferentes.

Relay permite centralizar servidores fora do domínio de broadcast e acrescenta contexto para selecionar o pool correto. Essa posição também cria uma fronteira de confiança que precisa ser protegida.

DHCPv6 usa mensagens e portas próprias e pode atribuir endereços, delegar prefixos ou fornecer apenas informações. SLAAC e Router Advertisement continuam com papéis próprios, especialmente a descoberta do roteador padrão.

Referências

• IETF — RFC 2131: Dynamic Host Configuration Protocol. Acesso em 29 ago. 2026.
• IETF — RFC 2132: DHCP Options and BOOTP Vendor Extensions. Acesso em 29 ago. 2026.
• IETF — RFC 3046: DHCP Relay Agent Information Option. Acesso em 29 ago. 2026.
• IETF — RFC 4361: Node-Specific Client Identifiers for DHCPv4. Acesso em 29 ago. 2026.
• IETF — RFC 9915 / STD 102: Dynamic Host Configuration Protocol for IPv6. Acesso em 29 ago. 2026.
• IETF — RFC 4861: Neighbor Discovery for IPv6. Acesso em 29 ago. 2026.
• IETF — RFC 4862: IPv6 Stateless Address Autoconfiguration. Acesso em 29 ago. 2026.
• IETF — RFC 3118: Authentication for DHCP Messages. Acesso em 29 ago. 2026.
• IETF — RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses. Acesso em 29 ago. 2026.