Resumo

  • O atual rascunho do V6OPS define IPv6-Only pelo uso nativo efetivo em um escopo identificado, não pelos protocolos instalados e nem por um estado uniforme de toda a rede.
  • IPv4 pode sobreviver como IPv4aaS, por NAT64, DNS64, CLAT ou SIIT-DC, além de permanecer no upstream, no controle, na administração ou em dispositivos legados.
  • Um registro de escopo e dependências deve vincular o rótulo ao objeto observado, à evidência, às exceções, aos responsáveis e à condição que autoriza substituí-lo.

A migração não acontece de uma vez

“Somos IPv6-only” parece uma conclusão simples. A operação, porém, é feita de partes que mudam em momentos diferentes. O provedor pode remover IPv4 nativo do enlace de acesso e manter a rede do assinante em pilha dupla. O data center pode atribuir só IPv6 aos servidores e receber clientes IPv4 por um relé de borda. O telefone pode estabelecer um contexto IPv6 e continuar oferecendo conectividade a aplicações IPv4 por meio de CLAT.

O rascunho do grupo V6OPS IPv6-Only and IPv6-Mostly Terminology Definitions procura impedir que essas configurações diferentes sejam comprimidas na mesma frase. A revisão 02 foi publicada em 11 de setembro de 2026, e o anúncio do I-D confirma que se trata de um item de trabalho do grupo. O Datatracker registra atualmente a fase de última chamada do WG. Isso não é aprovação pelo IESG nem RFC final. O histórico e a comparação entre 01 e 02 preservam a condição de texto ainda revisável.

O ponto central da revisão 02 é o escopo. O termo descreve a função realmente usada naquele lugar, não tudo que o equipamento é capaz de suportar. Um nó pode implementar IPv4 e IPv6, mas usar apenas IPv6 nativo em determinada interface. O tráfego IPv4 ainda pode atravessar o enlace encapsulado ou traduzido. O fato demonstrável é a ausência de IPv4 nativo ali; não é a eliminação de toda dependência institucional.

A diferença delimita autoridade. A equipe do acesso consegue responder pela configuração do enlace. Ela não necessariamente controla cada aplicativo, destino externo, dispositivo de cliente, ferramenta de fornecedor ou caminho de recuperação. Quando “enlace”, “VLAN” ou “plano de dados” é retirado do resumo executivo, a declaração passa a abranger sistemas sobre os quais o emissor original não tinha evidência completa.

Ausência nativa não significa ausência funcional

No vocabulário proposto, IPv6-Only significa que apenas IPv6 é nativo no escopo declarado. IPv4 não é configurado nem gerenciado ali, embora possa ser transportado sobre IPv6. IPv6-Only-Strict acrescenta que IPv4 também não é transportado, encapsulado ou traduzido dentro desse escopo.

São decisões diferentes. Retirar IPv4 nativo de uma camada pode economizar endereços e reduzir complexidade. Encerrar a função de compatibilidade exige que aplicações, parceiros, instrumentos de gestão e recursos externos não dependam mais dela. A primeira decisão é progresso legítimo; não constitui prova automática da segunda.

Os mecanismos de transição mostram para onde a função se desloca. A RFC 6877 define 464XLAT, combinando tradutores para que aplicações ou redes IPv4 operem sobre acesso IPv6. A RFC 6146 define NAT64 stateful entre clientes IPv6 e servidores IPv4, e a RFC 6147 trata de DNS64. A RFC 8585 organiza requisitos do roteador de borda do cliente em cenários de IPv4 como serviço.

Esses componentes não denunciam uma falha. Eles concentram compatibilidade em novos pontos: capacidade do tradutor, síntese de DNS, registros, comportamento de aplicações, suporte e responsabilidade do fornecedor. O custo de manter IPv4 nativo pode diminuir enquanto cresce a importância operacional da plataforma que traduz o tráfego restante. Um rótulo sem dependências mostra o benefício, mas não quem assumiu o risco.

O data center fornece outra imagem. A RFC 7755 descreve SIIT-DC, no qual nós internos IPv6 atendem clientes IPv4 por relés de borda. Chamar a LAN interna de IPv6-only é coerente. Concluir que cessaram a demanda IPv4, os mapeamentos e a obrigação de operar o relé não é. A compatibilidade mudou de localização.

O substantivo faz parte da prova

O rascunho diferencia acesso, segmento, host, serviço, API, plano de dados, controle e gestão. Uma empresa pode operar simultaneamente VLANs de pilha dupla, IPv6-only e IPv6-mostly. Uma rede móvel pode transportar IPv6 até o terminal e expor pilha dupla às aplicações. Uma nuvem pode ter sub-redes IPv6-only ao lado de outras que usam IPv4 privado.

“Plano de dados IPv6-only” não responde como o controle funciona. “Servidor IPv6-only” não esclarece como clientes IPv4 chegam. “Acesso IPv6-only” nada diz sobre a LAN do assinante. “Nuvem IPv6-only” pode ser largo demais quando interfaces e sub-redes divergem.

O escopo, portanto, não é uma observação opcional. É parte do conteúdo lógico da afirmação. Removê-lo cria uma nova frase, normalmente mais forte. Se o inventário técnico preserva o escopo, mas o relatório público o perde, houve uma mudança de conclusão sem uma nova medição.

Isso também evita comparações ruins. Um operador pode implantar acesso residencial IPv6-only com NAT64 central; outro pode manter um laboratório estrito sem qualquer transporte IPv4. Os dois rótulos cabem no vocabulário, mas objetivos e riscos não cabem numa única nota de maturidade. O registro escopado respeita a decisão local de cada um.

A carta do V6OPS dá prioridade à orientação operacional em contextos específicos, como provedores, empresas e centros de dados. A terminologia comum é uma interface para trocar experiências, não uma arquitetura imposta. Essa separação acompanha a tese de Heng Lu em Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: o mínimo compartilhado deve deixar espaço para decisões futuras e revisões locais.

IPv6-mostly não é uma porcentagem

O termo IPv6-Mostly não representa uma parcela do tráfego. O rascunho o usa para um escopo de pilha dupla com NAT64 e opção DHCPv4 108, podendo incluir DNS64, em que clientes IPv4-only, de pilha dupla e IPv6-only coexistem. IPv4 é fornecido sob demanda.

A RFC 8925 define a negociação. Um cliente capaz solicita a opção 108. Ao receber um valor válido, pode recusar o endereço IPv4 oferecido e interromper DHCPv4 pelo intervalo indicado ou até um novo evento de conexão. A capacidade vale por interface; não transforma o aparelho para sempre em um dispositivo IPv6-only.

Menos concessões IPv4 medem alocação, não todas as dependências. A proporção de pacotes nativos mede o enlace, não o tradutor. O inventário de NAT64 mede infraestrutura, não a experiência de cada aplicação. Testes de destino medem resultados, não a contingência fora de banda. A governança começa quando cada indicador declara sua pergunta.

Um registro pequeno para uma afirmação precisa

Não é preciso publicar endereços, topologia, clientes ou controles de segurança. É preciso impedir que o rótulo se solte do objeto. Para cada estado, o registro pode guardar:

  1. serviço, interface, enlace, VLAN, coorte de aplicações, plano ou rede inteira a que se refere;
  2. termo escolhido e versão do vocabulário;
  3. condição de encaminhamento nativo e método de observação;
  4. janela temporal ou versão de configuração;
  5. transporte, tradução, encapsulamento, endereçamento e alcance IPv4 que ainda restam;
  6. NAT64, DNS64, CLAT, SIIT-DC, proxy ou CDN dos quais o resultado depende;
  7. exceções de dispositivos, aplicações, controle, fornecedores e emergência;
  8. dono de cada dependência e autoridade capaz de alterar o rótulo;
  9. falha esperada e caminho de retorno;
  10. evidência que justificaria o próximo estado, decisão e data de substituição.

É um registro, não um certificado. O certificado sugere uma conclusão universal. O registro preserva decisões limitadas, datadas e corrigíveis. Operações pode enxergar simplificação; segurança, concentração; finanças, economia de endereços; produto, continuidade para clientes antigos. Não é necessário que uma autoridade central escolha uma leitura. É necessário que todas partam dos mesmos fatos.

Em The Policy Mirror, Heng Lu argumenta que políticas devem refletir sistemas e incentivos em funcionamento. Um marco público de “fim do IPv4” dá prestígio visível, enquanto a manutenção da compatibilidade continua pouco visível. Quanto maior a recompensa pelo anúncio, mais importante preservar o limite técnico que o torna verdadeiro.

O que não foi demonstrado

As fontes não apontam um operador que tenha usado o termo de modo enganoso. Não medem implantação, desempenho ou custo. A última chamada do WG pode alterar o texto, e uma eventual RFC informativa continuaria sem certificar qualquer rede concreta.

Também não se segue que tradutores devam ser desligados imediatamente. Eles podem viabilizar uma adoção de IPv6 que não exclua usuários. A pergunta responsável é outra: onde está a ponte, quem a opera, qual resultado ela mantém e o que deixaria de funcionar se fosse removida?

Um acesso IPv6-only pode ser uma conquista material e ainda ser apenas o acesso. Manter as duas verdades no mesmo documento transforma o avanço técnico em evidência governável.

Fontes