Resumo

  • A RFC 1887 tratou o multihoming como distribuição de custo: estabilidade interna podia exigir uma rota global, enquanto agregação pelo provedor podia exigir renumeração.
  • A RFC 2073 reservou campos para registro, provedor e assinante; a RFC 2374 removeu os bits de registro e a RFC 3587 tornou histórica a estrutura TLA/NLA que veio depois.
  • A agregação continuou sendo uma função operacional. O que deixou de ser permanente foi uma determinada tradução dessa função em hierarquia institucional.

O custo economizado aparecia em redes alheias

Em dezembro de 1995, a RFC 1887 observou que endereços contíguos permitiam resumir a alcançabilidade de muitos clientes em um prefixo. Menos entradas significavam menos memória, processamento e largura de banda para trocar rotas. A economia beneficiava sobretudo os roteadores distantes.

As RFCs 1518 e 1519 já haviam exposto essa lógica no CIDR: prefixos de tamanho variável podiam acompanhar a topologia. O espaço de 128 bits do IPv6 não eliminava a escassez de estado no sistema de roteamento.

A RFC 1887 separou dois objetivos que uma única tabela costuma misturar. A administração de endereços podia ser descentralizada; a agregação exigia coerência com conexões reais. Fronteiras corporativas, nacionais e institucionais não coincidiam necessariamente com o caminho dos pacotes. Por isso, “eficiência versus controle descentralizado” era uma escolha sobre onde manter as exceções.

Multihoming transformou a abstração em fatura

Com um prefixo independente dos provedores, uma organização mantinha numeração estável e anunciava o site como uma unidade. Porém, provedores possivelmente no mundo inteiro precisavam guardar uma rota explícita para ela.

Com um prefixo por conexão, cada provedor agregava seus clientes. O tráfego tendia a entrar perto do destino, mas uma falha podia isolar os endereços derivados daquele enlace. Alterar a conectividade externa também alterava endereços internos. Rotas extras recuperavam parte da redundância e consumiam parte da economia.

A terceira alternativa escolhia um prefixo principal e limitava a divulgação de atalhos. A quarta criava um prefixo comum para clientes ligados ao mesmo conjunto de provedores. Nenhuma zerava a complexidade; cada uma mudava sua localização.

O resumo da RFC 1887 foi explícito: as soluções impunham custos reais, inclusive financeiros, às organizações multihomed e aos domínios de trânsito — também àqueles sem vínculo com o cliente. A política de aceitar e propagar um prefixo não local era o ponto onde essa conta se tornava decisão.

Cinco bits institucionalizaram o registro

A RFC 2073, de janeiro de 1997, propôs um endereço com Format Prefix, Registry ID de cinco bits, Provider ID, Subscriber ID e uma parte interna de 64 bits. IANA aparecia como registro principal, com identificadores também para o espaço multirregional, RIPE NCC, INTERNIC e APNIC.

O desenho colocava a cadeia de alocação à vista. O registro organizava provedores e assinantes; o provedor estruturava seus assinantes; o assinante administrava o interior. Ainda assim, o encaminhamento usava longest-prefix match. O documento não excluía outros formatos e admitia espaço obtido diretamente de um registro, independente dos provedores conectados.

O nome Provider ID, portanto, não provava contrato vigente, origem BGP, propriedade nem entrega. Era evidência de uma posição em um modelo de alocação.

A primeira revisão retirou o registro

Em julho de 1998, a RFC 2374 tornou a RFC 2073 obsoleta e removeu os bits de registro por não serem necessários à agregação. Adotou TLA, NLA e SLA, separando topologia pública, topologia local e identificador de interface.

O formato passou a aceitar agregação por provedores e por pontos de troca. Um site ligado a um exchange poderia, em princípio, trocar o transporte de longa distância sem renumerar e usar mais de um sem receber um prefixo de cada. Mas seleção e portabilidade ficaram fora do escopo. A possibilidade geométrica não fornecia autenticação, prazos, recuperação ou uma obrigação de concluir a mudança.

Em agosto de 2003, a RFC 3587 tornou histórica a RFC 2374 e a estrutura TLA/NLA. O esquema fixo havia sido substituído por política coordenada dos RIRs; o texto admitia que ele talvez não fosse a melhor solução técnica naquele estágio e que a política evoluiria.

Restou a forma genérica: global routing prefix, subnet ID e interface ID. RIRs e ISPs ainda podiam estruturar o prefixo hierarquicamente; o site estruturava a sub-rede. A função permaneceu, enquanto os nomes institucionais saíram da semântica permanente.

Renumerar sem flag day ainda é renumerar

A RFC 4192 descreveu uma transição make-before-break: prefixos antigo e novo coexistem enquanto DNS, roteamento e configuração migram. Isso reduz interrupção, mas não inventaria automaticamente endereços embutidos em ACLs, monitores, certificados ou aplicações.

A RFC 4984 registrou que, para alguns sites, essas dependências tornavam a renumeração efetivamente impossível. Espaço PI reduzia o lock-in, porém adicionava entradas à zona sem rota default. Espaço PA agregava no provedor de origem, mas o anúncio por outro podia forçar desagregação.

O relatório apontou a sobrecarga de locator e identifier: a topologia pede mudança; a identidade pede estabilidade. Um único número serve mal aos dois objetivos quando eles divergem.

Até o /48 geral recomendado pela RFC 3177 foi revisto. A RFC 6177 rejeitou o tamanho único e alertou que poucos limites fixos poderiam recriar práticas classful. Manteve espaço suficiente como princípio e devolveu o tamanho exato ao julgamento operacional.

Preservar camadas para preservar a escolha

O registro de alocação prova uma delegação sob certa política e data. Uma observação BGP prova uma origem vista de determinado lugar. O contrato prova uma relação comercial. A telemetria prova caminho ou resultado. Um prefixo liga esses fatos, mas não permite substituir um pelo outro.

A lição dessa sequência não é abolir hierarquias. É impedir que uma hierarquia útil para comprimir rotas seja promovida a autoridade total sobre uso, titularidade e continuidade. Agregação deve ser medida; exceções e renumeração devem ter seus custos registrados; a política deve mudar sem apagar a proveniência.

Rotas podem ser resumidas. Responsabilidade não.

Fontes