Resumo

  • O RFC 1897 combinava ASN do provedor, parte da rede IPv4 do assinante, sub-rede local e identificador de interface, ao mesmo tempo em que classificava o endereço como temporário, recuperável e sujeito a renumeração.
  • O RFC 2471 levou a 6bone para 3FFE::/16 sob outra hierarquia. Registro, BGP4+ e deveres de pTLA tornaram o experimento operacional, mas não criaram autoridade permanente de produção.
  • O RFC 3701 encerrou novas alocações e marcou 6 de junho de 2006 como fim. A devolução à IANA fecha a alocação; eliminar cada dependência antiga exige uma verificação diferente.

Temporário não significava imaginário

O RFC 1897 destinou endereços a testes de software IPv6 em protótipo. Eles podiam ser configurados e roteados para essa finalidade, mas o texto proibiu seu uso geral na Internet. Também avisou, desde a origem, que seriam recuperados e que os participantes precisariam renumerar.

Essa combinação separava capacidade de autoridade. Um site podia receber o endereço, registrar o contato, anunciar uma rota, encaminhar um pacote e completar uma transação. Cada etapa era real. A primeira comprovava delegação; as seguintes comprovavam configuração, política, caminho e resultado. Nenhuma convertia uma licença experimental em propriedade ou direito indefinido de produção.

O formato tornava a dependência visível. Ele carregava o ASN de 16 bits do provedor atual, os 24 bits superiores da rede IPv4 roteável do assinante, uma sub-rede de 16 bits e um identificador de interface de 48 bits. Se o prefixo IPv4 passasse de 24 bits, a parte restante ocupava o campo de sub-rede. Quando disponível, uma identidade IEEE MAC normalmente fornecia o último componente.

Assim, o número costurava provedor, localização IPv4, enlace físico e interface. Isso acelerava o protótipo porque reaproveitava relações existentes. Também antecipava o custo de saída: trocar de provedor, reorganizar o IPv4, mudar o enlace ou adotar outra arquitetura implicava substituir referências em DNS, túneis, filtros, inventários e aplicações.

Quando o desenho mudou, o endereço teve de mudar

O RFC 1884 descreveu a arquitetura inicial de endereços IPv6 de 128 bits. O RFC 1887 propôs uma alocação hierárquica orientada a provedores, capaz de refletir topologia e reduzir pressão sobre o roteamento. O RFC 1897 materializou essa visão numa faixa de teste.

A arquitetura amadureceu. O RFC 2374 apresentou um formato agregável com TLA, NLA e SLA, separando a topologia pública da estrutura do site. O RFC 2471 tornou o RFC 1897 obsoleto e designou o TLA 0x1FFE, formando o prefixo de teste 3FFE::/16 para a 6bone.

O novo documento repetiu a advertência. O bloco era temporário, seria retomado e exigiria outra renumeração. A hierarquia NLA deveria representar redes de trânsito e sites finais da 6bone; cada organização controlava sua estrutura interna. Estar correto no novo formato provava compatibilidade com o experimento vigente, não um título duradouro.

Mais tarde, o RFC 3701 disse que a passagem do primeiro bloco 5F00::/8 para 3FFE::/16 ocorreu com poucos problemas. É um registro valioso de coordenação, mas não uma auditoria completa. A frase não demonstra que todos os hosts migraram da mesma forma nem que DNS, ACLs, túneis e software foram alterados sem custo.

Uma rede séria ainda podia ser um andaime

A 6bone adquiriu práticas robustas. Os RFCs 2546 e 2772 detalharam BGP4+, agregação, filtros, DNS, um registro no estilo RIPE-181, objetos de contato e política e responsabilidades dos pTLA. A participação era voluntária e benevolente, mas o dever de conter prefixos no escopo e corrigir anúncios indevidos era concreto.

Essas rotinas deram valor probatório ao laboratório. O objeto de registro mostrava quem assumia responsabilidade. A sessão BGP mostrava troca de informação. A rota aceita registrava uma decisão do plano de controle. Entrega de pacotes e sucesso de aplicação pediam observações adicionais. Nem o conjunto completo alterava a condição de validade do prefixo.

É preciso manter a escada: especificação, delegação, configuração, política, rota, encaminhamento e aplicação. Na saída, vem outra: obter a substituição sob autoridade de produção, instalá-la, atualizar DNS e túneis, rever controles de acesso e documentação, retirar a rota antiga e procurar referências residuais.

O calendário impediu que transição virasse permanência

Com mecanismos de alocação IPv6 de produção disponíveis, manter o backbone experimental para sempre criaria um sistema paralelo. O RFC 3701 encerrou novas alocações pTLA em 1º de janeiro de 2004 e marcou 6 de junho de 2006 para a desativação. Depois disso, os prefixos da 6bone não deveriam ser usados na Internet em nenhuma forma e poderiam ser filtrados. A IANA retomaria 3FFE::/16.

Não havia conversão automática para espaço de produção nem garantia de tamanho de prefixo. Cada participante precisava de autorização pelo processo apropriado. O texto também registrou que o grupo de trabalho anterior já não tinha supervisão da 6bone em seu mandato e assumiu o processo da IETF como fórum da decisão. Isso documenta uma escolha de governança, não o consentimento individual de todos.

O RFC 5156 anotou depois que 5F00::/8 e 3FFE::/16 haviam retornado à IANA e não deveriam aparecer na Internet pública até eventual realocação. A contabilidade superior estava encerrada. Ainda assim, uma devolução administrativa não remove automaticamente literais antigos de DNS, firewalls, código, logs e cadernos. Fechar a alocação e provar a extinção operacional são dois recibos.

Fontes