Resumo

  • RFC 5211 propôs preparação, transição e uma fase posterior a partir de janeiro de 2012, buscando conectividade predominantemente IPv6. O próprio texto a definiu como uma possibilidade informativa, sem criar obrigação.
  • Data e MUST tornam a intenção legível. Não provam que IPv6 era vendável, provisionado, roteado nos dois sentidos, escolhido pelo cliente ou capaz de concluir o serviço.

A virada de fase existia no papel

Publicado em julho de 2008, RFC 5211 tentou coordenar uma mudança que atravessaria provedores, fabricantes e organizações sem comando central. A preparação iria até 2009, a transição ocuparia 2010 e 2011 e a pós-transição começaria em janeiro de 2012.

O documento declarou seus limites. Era “um possível plano”; alternativas permaneciam válidas. Não obrigava nenhuma parte. Os termos de RFC 2119 serviam somente para descrever a proposta com clareza. A nota do IESG disse que o texto não era candidato a qualquer nível de padrão da Internet e não resultava da revisão técnica usual de consenso do IETF.

O plano podia organizar conversa, orçamento e sequência. Não podia ligar uma interface, aceitar um contrato ou observar um pacote. Quando a data chegou, a agenda avançou; o estado operacional continuou dependente de prova.

Oferecer envolve uma cadeia

TRANS1 e POST1 colocaram a oferta de Internet IPv6 no plano. Em operação, “oferecer” precisa indicar produto, praça, tecnologia de acesso, elegibilidade, pedido, prefixo, equipamento do cliente, rota de ida, retorno, DNS, monitoramento e suporte.

Um catálogo pode mostrar o serviço enquanto a qualificação recusa o endereço. Um prefixo pode ser entregue sem retorno. A rota pode existir enquanto a seleção de endereço mantém sessões em IPv4. Um teste pode passar, mas identidade, pagamento, correio ou API externa pode falhar.

Para o site, publicar AAAA é recibo de DNS, não de negócio concluído. Resolução, escolha, conexão, transação e continuidade têm evidências distintas. Um sucesso em um ponto não representa todos os clientes, sistemas ou horários. Predominância sem métrica e denominador é apenas linguagem de programa.

A palavra normativa não ganhou fiscal

RFC 5211 empregou MUST, SHOULD e MAY para deixar o plano inequívoco. Ao mesmo tempo, negou que isso criasse dever jurídico ou operacional. Não estabeleceu auditor comum, população, janela de teste nem sanção.

A distorção acontece quando a frase viaja. “Provedores MUST oferecer” entra numa planilha e sai como “a Internet concluiu a transição”. Somem o provedor, o produto, a região, o cliente, o momento e o verificador.

Cada verbo deve carregar seu recibo. Oferta exige catálogo e pedido aceito. Ativação exige configuração e rotas. Produção exige transações e suporte. Predominância exige população e período. Desligamento exige dependências, exceções e reversão testada.

POST4 rejeitou a leitura binária

A pós-transição não desligava IPv4. POST4 permitia que provedores continuassem oferecendo IPv4 e que organizações continuassem usando-o. O destino era coexistência com papel crescente de IPv6, não uma troca universal.

Por isso trabalhos posteriores trataram separadamente pilha dupla, tradução, roteador do cliente, conteúdo, empresa, segurança e IPv4-as-a-Service. Um núcleo IPv6-only, IPv4aaS, um portal dual-stack e uma aplicação antiga podem coexistir. Cada um possui seu próprio estágio.

Retirar IPv4 cedo demais rompe dependência invisível. Mantê-lo para sempre preserva custo, superfície de ataque e inércia. O calendário não escolhe entre esses riscos.

Novos documentos não preencheram os registros antigos

RFC 6144 observou em 2011 que o esgotamento IPv4 poderia chegar antes de adoção significativa de IPv6. RFC 6180 esperava uma cauda longa. RFC 6540 depois definiu suporte IPv6 como boa prática corrente para nós IP. Outros textos detalharam conteúdo, borda do cliente e empresas.

Isso demonstra evolução da especificação, não implantação automática. Status do documento, código compatível, opção habilitada, caminho implantado e resultado observado são estados diferentes. Uma meta perdida também não prova falha do protocolo; prova apenas que a data não produziu a realidade. Causa exige evidência de compras, incentivos, legado, capacidade e risco local.

Registrar o que o plano não podia executar

A trilha deve guardar plano, responsável, orçamento, produto, pedido, provisionamento, endereço, DNS, rotas de ida e volta, seleção, tráfego, resultado da aplicação, continuidade, exceções e retirada. Cada recibo identifica tempo, escopo, ator e procedência.

Não é necessário centralizar decisões. Um formato mínimo comum permite comparação, enquanto cada rede mantém seus critérios. A coordenação permanece voluntária, mas as afirmações passam a ser verificáveis.

A data continua útil como gatilho de revisão. Se a evidência divergir do programa, corrige-se o programa. Não se renomeia o estado da rede para proteger o cronograma.

Fontes

  1. Informações de RFC 5211
  2. RFC 5211 em HTML
  3. RFC 5211 em texto
  4. Datatracker do IETF: RFC 5211
  5. Histórico de RFC 5211
  6. Referências de RFC 5211
  7. Erratas de RFC 5211
  8. RFC 3932 — submissões independentes
  9. RFC 2119 — termos de requisito
  10. RFC 8174 — atualização da BCP 14
  11. RFC 6144 — tradução IPv4/IPv6
  12. RFC 6180 — orientação de transição
  13. RFC 6540 — suporte IPv6 necessário
  14. RFC 6589 — transição de conteúdo
  15. RFC 7084 — borda do cliente
  16. RFC 7381 — implantação empresarial
  17. RFC 8170 — cenários de implantação
  18. RFC 9099 — segurança operacional IPv6
  19. RFC 9313 — tecnologias IPv4 como serviço
  20. Heng Lu — camadas de realidade e poder simbólico
  21. Heng Lu — especificação inicial mínima
  22. Heng Lu — primazia do código em execução