Resumo

  • A versão 03 do rascunho individual de Mark Smith acrescenta uma saída para clientes que exigem DHCPv4 Router Option 3: o endereço DHCP do próprio host ou 127.0.0.1.
  • O texto prevê que os dois valores mantenham pacotes IPv4 não locais dentro do host e gerem ICMP Destination Unreachable. É uma proposta, não um resultado público de interoperabilidade.
  • Os testes citados pelo blog da LACNIC em 2 de outubro eram da versão 02, antes da nova alternativa.

Análise

Um gateway padrão deveria levar o tráfego para outra rede. Uma revisão recente de um rascunho DHCPv4 propõe que, para alguns clientes antigos, esse campo possa apontar de volta para o próprio equipamento.

Em 16 de outubro, Mark Smith publicou a versão 03 de “Nearly IPv6 Only Dual Stack Hosts”. A versão 02 havia expirado em 15 de junho. A nova edição mantém o caminho que omite Router Option 3 para clientes que aceitam ficar sem ela, mas acrescenta outra possibilidade para aqueles que supostamente a exigem: devolver como roteador o endereço DHCP entregue ao próprio host ou 127.0.0.1.

Não se trata de um gateway convencional. A RFC 2132 define a opção 3 como a lista de roteadores enviada pelo servidor DHCP ao host. O rascunho afirma que, sob uma máscara /32, qualquer um dos valores autoendereçados deveria manter no equipamento os pacotes destinados a IPv4 não local e produzir imediatamente um ICMPv4 Destination Unreachable. O ponto decisivo é como cada cliente interpreta essa rota. O texto não traz uma matriz de testes que mostre quais clientes aceitam os valores, qual rota instalam ou se as aplicações tentam novamente por IPv6.

Os ensaios divulgados anteriormente não cobrem essa mudança. O artigo de Alejandro Acosta no blog da LACNIC, publicado em 2 de outubro, aponta para a versão 02 e lista testes em Windows 11, Fedora 43, Raspberry Pi OS baseado no Debian Trixie, Chromecast e Google Nest. Também informa que smartphones não foram testados e pede mais testes. São observações anteriores à versão 03 e não validam a nova ramificação da opção Router.

Por isso, não basta verificar se o servidor DHCP consegue enviar o valor. Um piloto deve comparar separadamente o endereço do próprio host e 127.0.0.1, variando clientes, versões de sistema e configuração do servidor ou do relé DHCP. É preciso guardar o DHCP ACK, inspecionar a tabela de rotas instalada, capturar tráfego IPv4 para destinos externos ao host, verificar se o ICMP chega à aplicação e observar se ela recua para IPv6. A comunicação entre equipamentos no mesmo enlace merece teste próprio: bloquear o encaminhamento não prova que todo o IPv4 local desapareceu.

A proposta convive com a opção DHCPv4 108; não a substitui. A RFC 8925 permite que um host compatível informe que prefere operar apenas em IPv6 por certo período. O rascunho mira equipamentos que não reconhecem essa opção ou continuam esperando uma resposta DHCPv4. A novidade da versão 03 é uma hipótese de compatibilidade, não uma nova norma.

O Datatracker lista a versão 03 como um Internet-Draft individual ativo, sem fluxo RFC e com estado IESG “I-D Exists”. O próprio documento diz que não é respaldado pela IETF e não tem posição formal no processo de padrões. Indica Informational como status pretendido e expira em 19 de abril de 2027. Uma versão revisada mostra que a proposta continua sendo trabalhada; não que a IETF ou os fornecedores de sistemas operacionais a tenham adotado.

Para os operadores, essa ramificação é uma hipótese de teste, não uma configuração pronta para implantação ampla. Os dois valores precisam ficar separados em um piloto limitado e reversível até que haja evidência sobre rotas e fallback das aplicações. Uma troca DHCP bem-sucedida prova apenas que a concessão chegou ao host. Ainda é necessário medir como ele se comporta diante de um gateway que aponta para si mesmo.

Fontes