Resumo

  • Conservação, roteabilidade e registro eram objetivos diferentes e frequentemente conflitantes no RFC 2050; o documento exigia julgamento caso a caso.
  • A alocação e o cadastro sustentavam unicidade, contatos e análise de uso, mas não provavam anúncio, propagação, alcance, legitimidade jurídica ou direito permanente.

O detalhe decisivo do RFC 2050 está numa negativa. O texto dizia que a roteabilidade não era garantida de modo algum pela alocação ou pela designação de endereços IPv4. Não era uma nota lateral: era o limite que organizava o restante do sistema.

Conservar significava distribuir uma reserva finita conforme necessidade operacional e evitar estocagem. Tornar roteável significava favorecer uma hierarquia agregável para não inflar as tabelas. Registrar significava preservar unicidade e publicar informação útil para solução de problemas. O RFC reconheceu que economizar endereços e economizar rotas podiam apontar em direções opostas.

Uma alocação entregava espaço a um provedor para atender clientes. Uma designação delegava um bloco a uma empresa final, sem subdelegação. O registro anotava esses atos. A sessão BGP com o vizinho, a política de importação do trânsito e o caminho do pacote continuavam em outras mãos.

O cadastro tinha função operacional concreta. Informações de reatribuição identificavam usuário e contatos, mostravam quanto do bloco anterior havia sido consumido e alimentavam estudos. O RFC condicionava novo espaço à apresentação de cerca de 80% desses registros. Isso fortalecia a prestação de contas, não media tráfego.

Planos de sub-redes, máscaras, hosts, topologia, protocolos, limitações, alocações passadas e implantação podiam ser auditados. As referências a 25% de uso imediato, 50% em um ano e crescimento gradual descrevem o processo de 1996. São evidência histórica, não política contemporânea.

A arquitetura de RFC 1518 explicava o incentivo à agregação. Por isso RFC 2050 queria que a maioria obtivesse espaço do provedor de trânsito e devolvesse o bloco ao trocar de conectividade, após uma renumeração cuidadosa. Menos rotas globais vinham acompanhadas de mais dependência do fornecedor.

Blocos diretamente obtidos no registro atendiam casos específicos, como multihoming equilibrado. O documento, porém, repetia que esses blocos independentes eram os menos prováveis de serem roteáveis. Um provedor podia aceitar injetar um prefixo; outros podiam filtrá-lo para proteger suas próprias tabelas.

Daí surgem recibos que não se substituem: registro, base de autoridade, anúncio pretendido, observação em coletores, aceitação em diferentes redes e entrega de pacotes. Um ROA ou objeto de rota, quando existe, também não é anúncio. Visibilidade em BGP não é alcance universal. Ausência num coletor não é prova de desuso.

O texto de 1996 falava em empréstimos durante o contrato de conectividade, validade enquanto os critérios persistissem, auditoria, possível invalidação, aprovação de transferências e apelação até IANA. Essas cláusulas não decidem hoje propriedade, contrato, uso legítimo ou política regional.

A página do RFC Editor, o Datatracker e a consulta de errata mostram o documento como Historic. O RFC 7020 o substituiu em 2013, registrando que políticas e procedimentos haviam mudado.

O sucessor preservou a separação: gestão do conjunto, alocação hierárquica e exatidão registral continuaram como metas, enquanto anúncio real e forma de publicidade das rotas ficaram explicitamente fora do sistema de registros. A tecnologia mudou; o limite de competência permaneceu legível.

A nota do IESG merece leitura literal. Aprovar BCP 12 significava acreditar que o texto retratava a prática vigente. Não significava endossar nem recomendar a política. A reavaliação prometida para dezembro de 1997 não recebe, no pacote congelado, um desfecho autônomo que possamos inventar.

O antecessor RFC 1466, o contexto posterior de RFC 7249 e a análise de empréstimo de RFC 2008 delimitam épocas e temas. O registro IPv4 atual da IANA registra o presente da sua própria base, não o percurso de um pacote.

A imagem do livro de endereços de Heng Lu ajuda a separar cadastro e ruas. As camadas de realidade, a primazia do código em execução e a especificação inicial mínima são lentes editoriais atuais, não requisitos escritos por RFC 2050.

O documento foi honesto porque não prometeu o que não controlava. O registro podia dar unicidade e responsabilidade; a hierarquia podia melhorar a chance de agregação; só a soma de decisões autônomas e observações podia demonstrar a rota.

Fontes