Resumo

  • A máscara DHCPv4 /32 e a omissão da opção de roteador atendem ao cliente legado, mas retiram sua rota IPv4 comum para destinos fora do enlace.
  • As solicitações repetidas podem cessar, mas o host conserva uma concessão exclusiva e ainda pode receber pacotes de outros sistemas no enlace.

Silenciar a solicitação não devolve o endereço ao pool

Um equipamento antigo de pilha dupla pode continuar pedindo IPv4 mesmo quando o operador quer que seus aplicativos usem IPv6. Parar de responder talvez apenas mantenha o cliente enviando novas solicitações DHCPv4 sem retorno. O blog técnico do LACNIC publicado em 2 de outubro aponta um caminho mais restrito, descrito em um Internet-Draft individual: responder com campos DHCPv4 tradicionais e configurar a interface sem uma rota IPv4 comum para destinos fora do enlace.

A opção 1 do DHCPv4 fornece a máscara 255.255.255.255, ou /32. O servidor deixa de enviar a opção 3, que anunciaria um roteador. Com /32, os outros destinos IPv4 ficam fora do enlace. Sem roteador anunciado, o host não tem próximo salto para encaminhar esse tráfego. Ele recebe a configuração que pediu e pode parar de repetir a busca, mas não ganha uma rota IPv4 funcional para fora.

Isso não equivale a desligar IPv4. A interface configurada continua com endereço IPv4 e usa DHCPv4. O equipamento pode ter outras interfaces, rotas manuais, túneis ou aplicativos com outro comportamento. Um aplicativo talvez tente IPv6 depois da falha em IPv4, mas o draft descreve uma expectativa, não uma garantia para todos os sistemas e serviços.

Uma concessão única continua registrada

O draft destaca um custo fácil de perder de vista: o servidor DHCPv4 ainda precisa entregar um endereço único a cada host do mesmo enlace. Normalmente não se pode dar o mesmo endereço a todos os clientes silenciosos de um segmento compartilhado. A detecção de conflitos pode sondar o endereço antes do uso. Se dois clientes o recebem, o conflito pode aparecer; o draft alerta que devolver repetidamente o mesmo endereço em conflito pode causar um ciclo de DHCPDECLINE.

As solicitações podem diminuir sem que a alocação desapareça. A concessão ocupa uma entrada do pool até que o cliente libere o endereço ou o prazo dinâmico termine. A RFC 2131 define a alocação dinâmica como temporária e reutilizável quando deixa de ser necessária. Uma concessão ativa não mede tráfego nem prova que o endereço voltou a estar livre.

O efeito econômico depende do pool. Uma concessão em IPv4 público escasso mantém custo de oportunidade, mesmo que o host não consiga usar o endereço para alcançar destinos remotos pela rota habitual. O draft também considera pools link-local ou RFC1918. Um pool privado dedicado pode preservar capacidade pública, mas ainda exige endereços únicos, controle no servidor, gestão de conflitos e análise de sobreposição com a rede privada existente.

O texto permite reutilizar cuidadosamente um pool entre enlaces físicos diferentes quando o servidor DHCP está ligado diretamente a cada enlace. Não é uma autorização geral. Com DHCP relay, o servidor seleciona o pool usando o endereço do relay, então o draft exige unicidade em toda a rede retransmitida. Ignorar esse limite pode transformar uma economia aparente em erro de alocação.

Prazos longos reduzem renovações e prolongam a reserva

O draft sugere considerar concessões de um dia ou várias semanas porque esses hosts não deveriam chegar a destinos externos por IPv4 e um pool local ou privado pode ser amplo. Um prazo maior reduz renovações e trabalho do servidor, mas mantém o endereço reservado por mais tempo. Em um pool público escasso, menos mensagens DHCP não significam automaticamente mais endereços livres. O operador deve medir solicitações e dias de ocupação juntos. É uma inferência operacional do modelo, não um resultado medido pelo blog.

A opção 108 oferece outro caminho para outro grupo. A RFC 8925 padroniza IPv6-Only Preferred para clientes compatíveis em uma rede IPv6-mostly configurada para isso. Se cliente e servidor suportarem o mecanismo, o cliente pode deixar de receber IPv4 quando a rede fornece a funcionalidade necessária. Isso pode preservar o pool. O método /32 se destina a quem não entende a opção 108; o draft diz que os dois podem coexistir. Nenhum comprova sozinho que aplicativos, DNS64/NAT64 ou serviços necessários funcionam.

Sem gateway não significa sem firewall

Omitir a opção de roteador retira o caminho normal para destinos IPv4 fora do enlace, mas não torna a interface invisível aos vizinhos. A seção de segurança do draft diz que outro host no enlace ainda pode enviar pacotes IPv4 ao equipamento com máscara /32. Recomenda um firewall local que permita nessa interface somente DHCPv4 entre cliente e servidor ou relay.

“Este host não consegue iniciar uma conexão IPv4 roteada para fora” e “este host não pode receber pacotes IPv4” são afirmações diferentes. A primeira decorre da configuração proposta; a segunda não. É preciso manter política explícita para tráfego de entrada se houver serviços locais ou outro caminho para o equipamento.

O que mostram as fontes públicas

O blog do LACNIC relata que o autor, Alejandro Acosta, experimentou a técnica em Windows 11, Fedora 43, Raspberry Pi OS baseado no Debian Trixie, Chromecast e Google Nest. Também diz que smartphones não foram testados e pede mais validação. São ensaios relatados pelo autor, não replicação independente, amostra representativa ou evidência de implantação em produção. O próprio blog diz que as opiniões dos autores não necessariamente representam o LACNIC.

O documento citado é a versão 02 de um Internet-Draft individual. O Datatracker da IETF o registra como expirado em 15 de junho de 2026 e sem posição formal no processo de padrões da IETF. A expiração não demonstra rejeição técnica; o draft tampouco é padrão aprovado. As fontes analisadas não apresentam redução medida de broadcasts DHCP, série de ocupação do pool, resultado de fallback de aplicações nem auditoria de segurança de entrada.

Quem testar o método deve publicar separadamente solicitações repetidas por grupo; concessões e dias de endereço em pools públicos, privados e link-local; liberações, vencimentos e DHCPDECLINE; limites de relay e enlace; sucesso de aplicativos IPv6 em uma amostra; e regras de firewall de entrada. Silenciar a rede, recuperar endereços escassos, manter aplicações e controlar exposição são resultados distintos.

Fontes: