Resumo

  • Um cliente capaz inclui o código 108 na lista de parâmetros do DHCPv4. O servidor só deve devolver a opção “IPv6-Only Preferred” se o pool selecionado estiver explicitamente configurado como IPv6-mostly; o cliente, então, deixa de solicitar o endereço oferecido.
  • O limite mínimo é 300 segundos e o padrão da RFC é 1.800. A pausa acaba com o tempo ou com um novo evento de conexão. Cinco minutos são um mecanismo de retorno rápido, não a confirmação de que o IPv4 foi desligado para sempre.

A oferta feita para não ser aceita

Normalmente, um DHCPOFFER diz que há um endereço à disposição. Com a opção 108, a mesma conversa pode terminar sem lease. O cliente coloca o código na Parameter Request List do DHCPDISCOVER ou DHCPREQUEST. Ele não define o valor de quatro bytes; apenas informa que aquela interface consegue operar sem endereço IPv4 quando a rede oferece a funcionalidade necessária.

O servidor não pode presumir essa capacidade. A solicitação precisa estar no pacote e o pool escolhido deve ser IPv6-mostly. Se ambas as condições existem, o servidor inclui V6ONLY_WAIT. A RFC recomenda 0.0.0.0 no campo de endereço oferecido. Quando a infraestrutura não aceita essa forma, um endereço real disponível pode ser anunciado, mas não deve ser reservado, pois o cliente não é esperado para pedi-lo.

O ganho está na convivência. Um equipamento sem suporte à opção segue o fluxo normal e recebe IPv4. Outro que a solicita pode continuar apenas com IPv6. Dispositivos IPv4-only, dual stack e capazes de IPv6-only permanecem no mesmo SSID ou VLAN, sem multiplicar segmentos nem depender de um classificador central que conheça cada aplicativo.

É um mecanismo de autoridade limitada. Ele não decide quais aparelhos merecem IPv4, não fixa prazo político de migração e não invalida quem não participa. Coordena uma escolha entre uma interface e um pool específico.

Cinco minutos como orçamento de recuperação

O valor V6ONLY_WAIT tem 32 bits. Se vier abaixo do mínimo, o cliente aplica 300 segundos. A RFC 8925 define 1.800 segundos como valor padrão; os cinco minutos são o piso, e os dois não devem ser tratados como sinônimos.

Durante o intervalo, o cliente deve interromper a configuração DHCPv4 e pode desligar a pilha IPv4 na interface afetada. A decisão termina no vencimento ou em um evento de nova conexão, o que ocorrer primeiro. Assim, uma escolha feita no Wi-Fi do escritório não acompanha o notebook de forma cega para uma rede de hotel que talvez seja apenas IPv4.

A versão 07 do draft 6MOPS, de março de 2026, recomenda começar pelos 300 segundos para facilitar rollback rápido e aumentar depois, se a operação provar estabilidade. O documento continua sendo um Internet-Draft, não uma RFC. Sua proposta, porém, é mensurável: ao surgir uma dependência crítica, o operador deixa de enviar a opção e o cliente volta ao DHCPv4 após o tempo ou a reconexão.

O intervalo curto também tem custo. Uma população grande repetindo DHCPDISCOVER a cada cinco minutos pode pressionar a infraestrutura. Um relógio menor reduz a duração de uma escolha errada; um maior reduz tráfego de controle. Número de clientes, capacidade do servidor, frequência de incidentes e tempo de recuperação devem decidir o ajuste.

O timer não expressa insegurança sobre a transição. Ele protege a possibilidade de corrigir uma declaração de capacidade que estava errada.

As seis linhas do recibo

Um painel que mostre “opção 108 ativa” comprime demais a realidade. O recibo precisa de pelo menos seis linhas.

A primeira é a política da interface. Quem declarou o equipamento capaz, com qual CLAT, versão de sistema e conjunto de testes? A RFC chama isso de decisão de política; não há varredura automática de todos os aplicativos.

A segunda é a solicitação observada. O código 108 apareceu de fato na Parameter Request List? Sem ele, o servidor não recebeu consentimento para aquela resposta.

A terceira é o escopo do servidor. O pool que respondeu era exatamente o configurado como IPv6-mostly? Um recurso habilitado no equipamento não prova a configuração do pool atingido.

A quarta é a oferta. A opção tinha quatro bytes válidos, qual era o tempo e o endereço anunciado era 0.0.0.0 ou um endereço real não reservado? Uma captura controlada responde.

A quinta é o estado do cliente. Ele recusou o lease, parou DHCPv4 e respeitou o tempo? Como se comportou em INIT-REBOOT, renovação e reconexão? A transmissão do servidor não prova a execução do terminal.

A sexta é o resultado do serviço. PREF64 chegou? NAT64 estava alcançável? CLAT apareceu para software que só abre socket IPv4? O usuário concluiu sua tarefa? A tabela de leases não registra essas respostas.

Somente com as linhas separadas é possível afirmar que um cliente recusou um endereço, naquele pool, por determinado período, e que certas aplicações funcionaram ou falharam. “IPv4 desligado” esconde justamente a evidência que uma operação precisa.

A tradução continua sendo uma dependência

A RFC 8925 pressupõe NAT64 para alcançar destinos apenas IPv4. A opção 108 não negocia qual tecnologia será usada, não comunica o prefixo NAT64 e não verifica a rota até o tradutor.

A RFC 8781, também coescrita por Linkova, define uma opção de Router Advertisement para entregar PREF64 ao host. A RFC 9872 recomenda esse método baseado em RA para novas implantações e mantém a descoberta por DNS como fallback quando a opção não está disponível ou não é suportada. Até receber PREF64, aplicações IPv4-only e comunicações com destinos apenas IPv4 podem ficar prejudicadas.

O 464XLAT cobre outra necessidade. O CLAT do lado do cliente oferece uma face IPv4 a programas legados e transporta o tráfego sobre IPv6. Mas a RFC 6877 avisa que se trata de conectividade IPv4 limitada, não de uma substituição integral: conexões IPv4 de entrada e todos os modelos ponto a ponto não reaparecem.

Por isso, a opção 108 pode estar correta enquanto o serviço falha. O cliente recusou o endereço, mas o RA não trouxe PREF64. O prefixo chegou, mas a rota NAT64 quebrou. A tradução funcionou, mas a VPN bloqueou cabeçalhos de extensão IPv6. O navegador usou IPv6 nativo, enquanto um aplicativo com literal IPv4 não encontrou CLAT.

Cada incidente deve nomear a camada. Colocar tudo sob “problema de IPv6” impede saber se o DHCP cumpriu o contrato e qual componente deve ser consertado.

O sucesso enganoso do dual stack

Happy Eyeballs pode abandonar um caminho IPv6 ruim e usar IPv4 sem que o usuário perceba. Isso preserva a experiência, mas também mascara defeitos por anos. Quando o endereço IPv4 some, a falha antiga deixa de ter rota alternativa.

O draft 6MOPS organiza a exposição em etapas: primeiro sinalizar PREF64, depois ativar a opção 108 no servidor e, quando os terminais são gerenciados, avançar por dispositivo. O texto alerta que alguns sistemas já processam a opção por padrão e não oferecem botão para desligá-la. Para eles, a mudança no servidor produz uma mudança imediata em todo o grupo compatível.

Os slides apresentados por Linkova no IETF 118 descrevem pilotos em escritórios do Google, expansão por locais e percentuais de ativação que cresceram gradualmente. Também relatam queda no uso de DHCP e projeção de recuperação de endereços. Esses números pertencem àquela apresentação e àquele ambiente; não são métricas universais nem medição independente.

O método é mais importante que o número: começar com uma coorte limitada, observar, ampliar e conservar o retorno. Documentos especificam uma hipótese operacional. Leases, pacotes e incidentes dizem se ela sobreviveu à rede real.

A demanda que um lease recusado consegue provar

Um endereço não aceito fica disponível para outro equipamento. Em redes que entregam IPv4 público aos terminais, isso pode reduzir consumo público. Com RFC 1918, pode aliviar o esgotamento do espaço privado e evitar outra camada de NAT. Segmentos novos podem nascer com pools menores; nos antigos, talvez seja preciso renumerar para que as folgas se tornem um bloco reutilizável.

Mas o sinal tem condições. Ele diz que esta interface, com esta versão, esta política e estes serviços de tradução, não tomou um endereço durante o intervalo. Não diz que todos os aplicativos tiveram êxito, que o dispositivo fará o mesmo em outra rede ou que quem continuou usando IPv4 não tinha necessidade.

Também não apaga a escassez. A demanda pode se concentrar nos usos que realmente não conseguem sair. A utilidade econômica está em separar alocação automática de necessidade observada, não em proclamar que o endereço perdeu valor.

O painel deve mostrar clientes que pediram o código, respostas válidas, leases evitados, retornos posteriores, falhas por aplicativo, saúde de NAT64/CLAT e endereços que de fato puderam ser retirados ou reaproveitados. Uma vaga no pool sem redimensionamento ainda não é capital recuperado.

O relógio de cinco minutos evita uma conclusão permanente. A rede registra um “não agora”, observa o efeito e mantém o direito de responder diferente na próxima rodada.

O papel documentado de Jen Linkova

A RFC 8925 lista Lorenzo Colitti, Jen Linkova, Michael C. Richardson e Tomek Mrugalski. Linkova também aparece, com outros autores, na RFC 8781, na RFC 9872 e no draft 6MOPS atual. O conjunto comprova participação continuada em mecanismos relacionados de operação IPv6. Não comprova invenção exclusiva nem controle de sistemas, fabricantes ou implantações.

Essa cautela combina com o desenho. O texto define semântica interoperável. O cliente escolhe pedir, o operador configura o pool e o código em execução produz o resultado. Equipamentos que não adotam a opção continuam no DHCPv4 comum; não se tornam inválidos por decisão institucional.

A contribuição durável não é uma data para o fim do IPv4. É ter reduzido uma pergunta enorme a um teste pequeno: nesta conexão, por este tempo, o endereço pode ficar de prontidão? Ao final, o sistema continua autorizado a perguntar novamente.

Fontes