Resumo

  • Option 108 permite que um cliente apto a IPv6-only peça para não receber IPv4; o servidor responde apenas em um pool IPv6-mostly configurado.
  • O rascunho não define quem está pronto. A política de dispositivos, a saída de emergência e as falhas antes escondidas pelo IPv4 ficam com o operador.

Um servidor DHCP não examina os aplicativos de um notebook para garantir que o dia do usuário seguirá normal sem IPv4. Option 108 não tenta fazer isso. O cliente pode dizer que aceita abrir mão do endereço; o operador decide em quais redes aceita essa declaração.

A versão 12 do rascunho do IETF foi atualizada em 29 de outubro e está em Last Call do IESG até 12 de novembro. IPv4 e IPv6-only compartilham o segmento. Se o cliente pede Option 108 e a recebe no DHCPOFFER, não deve solicitar o IPv4 oferecido. Quem não suporta a opção ainda pode receber IPv4 de um pool IPv6-mostly.

Option 108 é sinal, não teste. O rascunho diz que “IPv6-only-capable” não tem definição técnica estrita: o aparelho deve funcionar sem IPv4 nativo e preservar a experiência do usuário. Aplicativos podem usar IPv6. NAT64 abre destinos IPv4-only; ou o aparelho executa CLAT, o tradutor do lado do cliente da RFC 6877, para aplicações antigas. A RFC 8925 já trata a declaração de capacidade de uma interface como decisão de política. A troca DHCP não revela se o aparelho está pronto. Alguém escolhe quais dispositivos e usuários podem fazer essa declaração.

O servidor só envia Option 108 quando o cliente a pediu e o pool foi explicitamente configurado como IPv6-mostly. O valor de quatro bytes diz por quantos segundos o DHCPv4 fica desativado. O servidor envia V6ONLY_WAIT, ou zero se não houver temporizador. É o pool que decide onde o IPv4 some.

Destinos IPv4-only ainda exigem NAT64 e anúncio do prefixo por Router Advertisement, conforme RFC 8781, DNS64, conforme RFC 6147, ou ambos. Se o dispositivo, DNS, tradutor ou acesso falhar, desaparece o fallback dual-stack que escondia o defeito.

O rascunho recomenda piloto voluntário e ativação gradual de PREF64 e Option 108 com uma saída para quem encontrar problemas. Considera até que o usuário tenha de reportar a falha para sair. Isso ajuda a detectar defeitos, mas transforma a pessoa afetada na primeira equipe de testes.

ACL para bloquear IPv4 fica como solução temporária: a política por aparelho envelhece quando os dispositivos circulam.

O rascunho não traz contagem de implantações nem falhas observadas, portanto não comprova economia de endereços ou experiência do usuário. Seu argumento é arquitetural: uma rede comum pode deixar de dar IPv4 a quem vive sem ele e preservar a concessão para os demais. Falta provar a “prontidão” antes que o suporte descubra a resposta aplicativo por aplicativo.

IETF draft -12 · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147