Hoje vamos falar sobre o Internet Draft chamado: “Hosts de pilha dupla quase exclusivos do IPv6” (Nearly IPv6 Only Dual Stack Hosts)
Introdução
Este documento técnico propõe um método para gerenciar dispositivos de pilha dupla (dual stack) que não requerem conectividade IPv4, mas continuam gerando tráfego de rede ao solicitar endereços automaticamente (como cliente DHCPv4).
A estratégia consiste em designar-lhes uma máscara de sub-rede 255.255.255.255 por meio do DHCPv4, o que efetivamente isola o equipamento; isso impede a comunicação com destinos externos sob esse protocolo. Ao omitir a configuração de um gateway ou roteador, o tráfego é direcionado para o protocolo IPv6, eliminando a necessidade de suporte para opções de rede mais modernas e complexas. Essa técnica reduz o ruído na rede local e permite a reutilização de faixas de endereços privados sem afetar o roteamento global. Além disso, o autor sugere a implementação de períodos de concessão de endereços mais longos para minimizar a carga nos servidores. Em resumo, apresenta-se uma solução prática para a transição para redes só IPv6 usando mecanismos de infraestrutura tradicionais.
(Acesso livre, não requer assinatura)
O problema que se procura resolver
O rascunho resolve o problema de como silenciar solicitações DHCPv4 ruidosas dos dispositivos mais antigos e remover de forma efetiva o acesso ao IPv4 (forçando-os a usar o IPv6), usando os mecanismos DHCPv4 tradicionais que esses mesmos dispositivos mais antigos já entendem, sem a necessidade de atualizar seu software.
Especificamente, o documento aborda os seguintes problemas interligados:
Tráfego de lixo na rede local (broadcasts infinitos): Quando uma rede de pilha dupla deseja migrar para um ambiente só IPv6, o passo lógico seria parar de entregar endereços IPv4 aos dispositivos. No entanto, se a designação do IPv4 for simplesmente desativada, os sistemas operacionais dos hosts continuarão enviando solicitações DHCPv4 de forma periódica, e malsucedida. Lembre-se de que este tráfego DHCPv4 é geralmente broadcast.
Incompatibilidade de dispositivos antigos com soluções modernas: Muitos já conhecem as redes IPv6-Mostly, nas quais a Opção 108 do DHCPv4 (IPv6-Only Preferred) é a chave. E qual é o problema? Essa opção permite que um “dispositivo moderno” informe ao servidor que prefere não receber um IPv4 se houver IPv6 disponível. Em outras palavras, o problema é que os dispositivos antigos não reconhecerão essa opção DHCPv4 e continuarão enviando broadcast indefinidamente.
O “dilema” da designação do IPv4: Os administradores de rede são obrigados a continuar oferecendo endereçamento IPv4, mantendo uma rede IPv6 e servidores DHCPv4 apenas para ‘manter calados’ os clientes mais antigos.
Solução proposta
Na minha humilde opinião, a solução é muito criativa.
O problema que se procura resolver
O rascunho resolve o problema de como silenciar solicitações DHCPv4 ruidosas dos dispositivos mais antigos e remover de forma efetiva o acesso ao IPv4 (forçando-os a usar o IPv6), usando os mecanismos DHCPv4 tradicionais que esses mesmos dispositivos mais antigos já entendem, sem a necessidade de atualizar seu software.
Especificamente, o documento aborda os seguintes problemas interligados:
Tráfego de lixo na rede local (broadcasts infinitos): Quando uma rede de pilha dupla deseja migrar para um ambiente só IPv6, o passo lógico seria parar de entregar endereços IPv4 aos dispositivos. No entanto, se a designação do IPv4 for simplesmente desativada, os sistemas operacionais dos hosts continuarão enviando solicitações DHCPv4 de forma periódica, e malsucedida. Lembre-se de que este tráfego DHCPv4 é geralmente broadcast.
Incompatibilidade de dispositivos antigos com soluções modernas: Muitos já conhecem as redes IPv6-Mostly, nas quais a Opção 108 do DHCPv4 (IPv6-Only Preferred) é a chave. E qual é o problema? Essa opção permite que um “dispositivo moderno” informe ao servidor que prefere não receber um IPv4 se houver IPv6 disponível. Em outras palavras, o problema é que os dispositivos antigos não reconhecerão essa opção DHCPv4 e continuarão enviando broadcast indefinidamente.
O “dilema” da designação do IPv4: Os administradores de rede são obrigados a continuar oferecendo endereçamento IPv4, mantendo uma rede IPv6 e servidores DHCPv4 apenas para ‘manter calados’ os clientes mais antigos.
Solução proposta
Na minha humilde opinião, a solução é muito criativa.
Procura-se atender às necessidades do host/cliente. O cliente quer um endereço IPv4 fornecido pelo servidor DHCP. O que o servidor DHCP faz? Tudo bem, vou te dar um. O que o cliente “matematicamente não sabe” é que esse endereço IP é praticamente inútil.
Não vou abordar todas as ideias mencionadas no draft, mas sim as duas mais interessantes:
A solução proposta no rascunho (Internet-Draft) para permitir que os hosts de pilha dupla (dual-stack) operem de maneira quase exclusiva no IPv6 consiste em um método sutil, porém altamente eficaz, baseado na configuração do DHCPv4 tradicional:
Configurar uma máscara de sub-rede /32 (255.255.255.255): Por meio da opção 1 do DHCPv4 (Subnet Mask), o cliente recebe uma máscara de sub-rede de host único. Ao receber essa máscara, o dispositivo conclui que não existe nenhum outro endereço IPv4 no seu próprio link físico, ou seja, todo o tráfego IPv4 para o exterior é considerado automaticamente como fora de seu link ou off-link.
Omitir a entrega de roteadores (gateways): O servidor DHCPv4 não fornece nenhum endereço de roteador ao cliente (a Opção de Roteador, opção valor 3, é removida deliberadamente).
Dessa maneira, o host antigo satisfaz sua necessidade de obter um endereço IPv4 (silenciando as requisições de broadcast repetitivas), mas fica isolado da rede IPv4 e é forçado a se comunicar exclusivamente via IPv6 (adicionalmente devemos somar o tráfego broadcast do ARP).
Como o procedimento acima isola um host no mundo IPv4?
O efeito da máscara /32: Ao configurar a interface do host com uma máscara 255.255.255.255, o sistema operacional entende que não há nenhum outro endereço IPv4 no seu próprio link. Portanto, para o host, absolutamente qualquer endereço IPv4 externo é considerado fora de seu alcance.
Procura por um roteador inexistente: Ao presumir que todos os destinos IPv4 estão em redes externas, o host tentará enviar qualquer pacote IPv4 por meio de seu gateway ou roteador padrão. No entanto, o método do draft consiste em não fornecer nenhum roteador via DHCPv4.
Até aqui, o host atende à sua necessidade de obter um IP via DHCPv4 e, além disso, não gera tráfego de broadcast repetitivo na rede.
Quais vantagens este método oferece em relação às redes IPv6-Mostly?
A principal vantagem deste método (fornecer uma máscara de sub-rede 255.255.255.255 e não entregar o gateway padrão) em relação à Opção 108 (IPv6-Only Preferred) é a compatibilidade com dispositivos e servidores legados (antigos).
Não requer suporte para protocolos recentes: A Opção 108 é um mecanismo do DHCPv4 relativamente novo, o que exige que tanto o sistema operacional do host (cliente) quanto o servidor DHCPv4 a suportem explicitamente. O método da máscara /32 (255.255.255.255) funciona usando mecanismos tradicionais de DHCPv4, tornando-o compatível com sistemas legados que não suportam a Opção 108.
Evite tráfego de broadcast desnecessário: Se o endereçamento IPv4 simplesmente deixasse de ser fornecido a um host antigo que não suporta a Opção 108, este continuaria enviando solicitações DHCPv4 periódicas e não atendidas, inundando o enlace local com tráfego de broadcast desnecessário. Este método atende à sua solicitação DHCPv4, fornecendo um endereço IP, mas restringe sua conectividade.
Economia e flexibilidade no endereçamento IPv4: Como os hosts configurados com a máscara 255.255.255.255 não tentarão alcançar destinos IPv4 fora de si mesmos, os endereços designados não precisam ser roteáveis nem na rede interna nem na Internet. Isso permite usar faixas não roteáveis, como o endereçamento link-local (169.254.0.0/16) ou blocos privados RFC1918, e até mesmo reutilizar o mesmo pool de endereços IP em diferentes enlaces físicos, caso o servidor DHCPv4 esteja diretamente conectado a eles.
IPv6 Mostlye Nearly IPv6 Only Dual Stack hosts não são mutuamente exclusivos
Vale ressaltar que ambas as abordagens não são mutuamente exclusivas e podem coexistir: uma rede implantada com a Opção 108 para que os hosts modernos não consumam endereços IPv4 dos pools do DHCPv4, ao mesmo tempo que aplica o método da máscara 255.255.255.255 (sem default gateway) para silenciar a conectividade IPv4 dos hosts legados.
Por que o draft expirou?
O documento em questão expirou em 15 de junho de 2026.
Sem entrar nos detalhes políticos da IETF, pode-se resumir que os rascunhos da Internet são documentos de trabalho temporários com validade máxima de seis meses, prazo no qual algum dos autores deve atualizar o documento para evitar o seu descarte.
Dado que essa data já passou, o draft expirou automaticamente ao não ser substituído por uma nova revisão ativa. Apesar de possuírem validade máxima de seis meses, os Internet-Drafts (I-D) podem ser atualizados ou substituídos por outros documentos a qualquer momento. Para reativá-lo, basta que o autor ou os colaboradores publiquem uma nova versão.
Quais sistemas operacionais foram testados?
O autor testou com sucesso este método nos seguintes sistemas operacionais e dispositivos:
Windows 11.
Várias distribuições Linux (ou sistemas baseados nesse núcleo) que usam diferentes clientes DHCPv4:
Fedora 43.
Raspberry Pi OS (baseado no Debian Trixie).
Dispositivos Chromecast.
Dispositivos Google Nest.
Do outro lado, é mencionado explicitamente que não foram realizados testes em telefones inteligentes (smartphones)
Conclusões
Essa técnica força o uso do IPv6 ao simular uma conexão IPv4 funcional, eliminando o tráfego de broadcast desnecessário de equipamentos antigos sem a necessidade de atualizações de software. O método, compatível com sistemas como Windows 11 e Linux.
É muito importante realizar testes extensivos em diversos sistemas operacionais e em diferentes redes (Dual Stack, Single Stack v4, Single Stack v6). Testar em qual cenário o comportamento é melhor, por exemplo, ao receber uma máscara 255.255.255.255 via o DHCP ou ao receber um endereço IP sem gateway padrão. É muito cedo para tomar qualquer decisão.
Prometo testar essa solução muito em breve, junto com a Opção 108, em alguma rede IPv6-Mostly.
Necessitamos de mais compatibilidade em diversos sistemas operacionais e diferentes versões. Sua colaboração é fundamental para oferecer uma experiência impecável. Se quiser participar deste processo, entre em contato conosco pelo e-mail: imasd@lacnic.net
Encontre mais informações e recursos úteis sobre como implementar o IPv6 aqui.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
