A restrição de 32 bits era técnica; o regime de racionamento era político

Resumo

• ARFC 791fixou cada endereço IPv4 de origem e destino em 32 bits e inicialmente interpretou os endereços unicast comuns por meio de três classes; ela não prescreveu registros regionais, previsões de demanda, testes de utilização, dependência de provedores, auditorias, sanções ou recursos.
• Os 2^{32} valores possíveis, ou seja, 4 294 967 296, nunca constituíram um reservatório único de endereços de host públicos atribuíveis. A estrutura de classes, valores especiais, reservas, blocos alocados, visibilidade de roteamento e uso real criaram diferentes denominadores que não podem ser combinados.
• De 1993 a 1996, as diretrizes publicadas selecionaram regras decisivas: previsões de 24 meses e limites de classe B na RFC 1466; agregação baseada em topologia na RFC 1519; e alocações progressivas, hierarquia de provedores, testes de utilização, auditorias, devolução de endereços e recursos ao registro pai na RFC 2050.
• A conservação e a agregação respondiam a riscos técnicos reais, especialmente o desperdício por classes e o crescimento das tabelas de roteamento. O elemento político não residia na invenção da escassez, mas no fato de que instituições identificáveis escolheram entre meios possíveis de distribuir custos, autoridade, exceções e recursos.
• Os registros públicos de alocação mostram os resultados positivos, não as solicitações, recusas, revisões, atrasos ou conselhos informais que os produziram. O texto do regime e sua justificativa técnica podem ser reconstituídos com mais confiança do que seu pleno efeito distributivo.

A arquitetura fixou o limite; a administração escolheu o teste

Dois documentos datados estabelecem a distinção essencial.

Em setembro de 1981, a RFC 791 especificava um campo Endereço de Origem e um campo Endereço de Destino, cada um com 32 bits. Ela definia um endereço de Internet como quatro octetos e dividia sua interpretação unicast comum inicial entre os formatos de classe A, classe B e classe C. Um endereço de classe A usava um bit de identificação de classe, sete bits de número de rede e 24 bits de endereço local. A classe B usava dois bits de classe, 14 bits de número de rede e 16 bits de endereço local. A classe C usava três bits de classe, 21 bits de número de rede e oito bits de endereço local. Eram características do protocolo, declaradas na discussão sobre endereçamento e na especificação do cabeçalho.RFC 791, setembro de 1981, seções 2.3 e 3.1, páginas 7 e 11–12

Em maio de 1993, a RFC 1466 recomendava que um registro dimensionasse atribuições contíguas de classe C a partir da projeção do solicitante dos endereços de sistema final necessários nos 24 meses seguintes. Uma projeção inferior a 256 endereços correspondia a um número de rede classe C; inferior a 512, a dois; inferior a 1 024, a quatro; e assim sucessivamente, até 64 números de rede classe C contíguos para uma projeção inferior a 16 384. Para uma classe B, o documento indicava que um solicitante deveria justificar mais de 32 sub-redesemais de 4 096 hosts, apoiados por um plano técnico cobrindo os 24 meses seguintes.RFC 1466, maio de 1993, seções 4.2.1 e 4.3, páginas 6–8

A RFC 1466 era de natureza informativa. Seu aviso de status indicava expressamente que não especificava um padrão da Internet. Elise Gerich é a autora; o resumo menciona apoio geral às suas recomendações por parte do Federal Engineering Planning Group agindo em nome do Federal Networking Council, dos co-presidentes do Intercontinental Engineering Planning Group e da RIPE. Essa combinação constitui evidência de uma recomendação feita por um autor com apoio institucional. Não prova que cada registro implementou imediatamente cada limite, que uma ação normativa da IETF impôs a política ou que cada rede envolvida concordou.RFC 1466, status, resumo e agradecimentos, páginas 1 e 9

O protocolo e a recomendação respondiam a perguntas diferentes. Um campo de 32 bits definia o espaço matemático externo. Não escolhia um horizonte de previsão, uma hierarquia de alocação, uma fórmula de utilização, uma região geográfica, um poder de auditoria ou uma via de recurso. As regras podiam ser respostas prudentes a restrições reais, mas não eram dedutíveis do cabeçalho.

Esse é o sentido restrito depolíticaaqui. Identifica uma decisão tomada por uma instituição nomeada, autora ou encarregada da implementação, entre arranjos técnica e administrativamente plausíveis, onde a escolha deslocou a autoridade ou impôs custos diferentes em termos de documentação, prazos, dependência de provedores, roteamento, renumeração ou revisão. Isso não significa que a escassez foi fabricada, que os atores eram partidários ou que suas escolhas eram corruptas. Coloca as questões de quem escolheu a regra, qual parâmetro alternativo poderia ter sido mantido nas condições da época e sobre quem recaíram o ônus ou a autoridade resultantes.

Um mesmo espaço de endereçamento produziu vários denominadores incompatíveis

A aritmética familiar é exata:

[2^{32}=4,294,967,296]

Sua unidade são valores binários nominais por campo de endereço de origem ou destino de 32 bits. Não é uma contagem de hosts públicos atribuíveis, organizações, conexões de clientes, atribuições de registros, prefixos roteados ou solicitações de espaço.

Os bits de classe imediatamente dividiram esse espaço matemático. O campo bruto de número de rede classe A continha 2^7 = 128 padrões binários; a classe B continha 2^{14} = 16 384; e a classe C continha 2^{21} = 2 097 152. A contabilidade administrativa não tratava cada padrão bruto como um número de rede comum. A tabela de maio de 1992 da RFC 1466 contava, em vez disso, 126 números de rede classe A, 16 383 classe B e 2 097 151 classe C. Esses números representam populações de números de rede por classes, e não valores de endereços ou organizações.

A tabela também registrava 49 números de rede classe A alocados, 7 354 classe B e 44 014 classe C em maio de 1992. São entradas bem-sucedidas em uma tabela administrativa particular. Não revelam nem o número de solicitantes, nem quantos endereços estavam ocupados, anunciados, acessíveis ou solicitados.RFC 1466, seção 3, tabela 1, página 3

Uma auditoria defensável dos denominadores separa, portanto, as seguintes populações.

Essas distinções não são preciosismo semântico. Cada linha responde a uma pergunta diferente. Uma alocação de primeiro nível reduz um pool administrativo sem mostrar que o espaço alocado é anunciado. Uma rota pode cobrir um grande bloco com poucos pontos terminais ocupados. Várias rotas podem representar uma única alocação. Uma atribuição pode permanecer não utilizada, enquanto um host pode ter vários endereços ou interfaces. A própria RFC 791 previa hosts com múltiplas interfaces físicas e múltiplos endereços de Internet lógicos. Um registro e uma tabela de roteamento não podem ser fundidos simplesmente porque ambos contêm prefixos.

A convenção usual de identificação de hosts da época criou ainda outra população. A RFC 1519 descrevia uma rede classe C como suportando no máximo 2^8 – 2 = 254 identificadores de host comuns, e uma classe B como suportando no máximo 2^{16} – 2 = 65 534, após exclusão dos valores locais todo-zero e todo-um usados segundo a convenção citada. São identificadores comuns potenciais dentro de uma rede, e não contagens de hosts conectados.RFC 1519, padrão proposto, setembro de 1993, seção 1, páginas 1–2

Suponha, apenas para escala, que um identificador seja necessário para cada um dos 600 hosts conectados. Os 65 534 identificadores comuns de uma classe B forneceriam 65 534/600 = 109,223 vezes a necessidade declarada, deixando 65 534 – 600 = 64 934 identificadores comuns fora dessa necessidade imediata. O cálculo demonstra a granularidade por classes; não prova que um verdadeiro solicitante de 600 hosts não precisava de nenhuma reserva, tinha uma topologia plana ou podia operar com um bloco sem classe arbitrária.

A RFC 1466 propôs um exemplo diferente para 600 hosts. Se 600 hosts estivessem distribuídos igualmente por dez Ethernets e a topologia tornasse difícil usar um bloco classe C compartilhado, o subscritor poderia receber dez números de rede classe C, um por Ethernet, sujeito a uma justificativa técnica para se desviar da tabela padrão em potências de dois. A unidade considerada eram então números de rede classe C, e não 600 endereços retirados de um pool livre.RFC 1466, seção 4.3, página 8

As evidências posteriores exigem a mesma cautela. O estudo da CAIDA sobre o consumo de IPv4 foi construído a partir de um arquivo IANA coletado em 14 de setembro de 2005 e de instantâneos WHOIS tomados em 31 de agosto de 2005 para ARIN, APNIC, LACNIC e RIPE. Faltava um instantâneo AFRINIC. A CAIDA removeu as diferenças de formato para criar uma representação comum e limitou as linhas de cada RIR ao espaço associado a esse registro no arquivo IANA, reduzindo as aparições duplicadas causadas por migrações e encaminhamentos. Ela agrupou o material legado migrado em um conjunto separado "diversos".CAIDA, "IPv4 Consumption Rates", metodologia e advertências

Seus números usavam o volume de endereços, comumente expresso em quantidades equivalentes/8. Eles distinguiam as alocações da IANA, a primeira ocorrência em um registro a jusante e a atribuição mais específica encontrada nos dados. A CAIDA indicou expressamente que os gráficos mostravam alocações, e não anúncios ou acessibilidade. Ela também explicou que uma limpeza da IANA atribuiu a data de agosto de 1993 a muitos registros legados para os quais as datas históricas precisas não estavam disponíveis. São datas administrativas reconstituídas, e não datas de transação recuperadas.CAIDA, metodologia, advertências e figuras 1–7

A reconstituição é útil para mostrar por que os níveis administrativos devem ser separados. Não constitui evidência contemporânea da experiência dos solicitantes em 1993. Não mede solicitações, recusas, revisões, rotas, anúncios, hosts acessíveis, interfaces ocupadas, motivações ou causalidade política.

O artigo de Richter, Allman, Bush e Paxson,A Primer on IPv4 Scarcity, é ainda mais tardio. Foi submetido em 10 de novembro de 2014, revisado em 27 de fevereiro de 2015 e publicado como contribuição editorial noACM Computer Communication Review45(2) em abril de 2015. Constitui uma síntese retrospectiva valiosa e uma pista de fontes para os desenvolvimentos técnicos, institucionais e da era do esgotamento. Não pode estabelecer o que um ator sabia em 1981–1998, como um solicitante da época vivenciou a interação com um registro, se um mecanismo foi implantado, ou se os contemporâneos aderiam a uma doutrina posterior de mercado ou propriedade.Richter et al., "A Primer on IPv4 Scarcity", aviso de publicação

O limite matemático externo era único. A escassez operacional não era. Manifestava-se nas contagens de números de rede por classes, faixas reservadas, detenções dos registros, unidades de atribuição e estado dos roteadores, cada um com sua própria data e denominador.

O desperdício por classes e a pressão sobre o roteamento eram reais

A primeira pressão imediata vinha da granularidade. Uma organização necessitando de mais de 254 identificadores de host comuns não dispunha de uma unidade de alocação por classes proporcionada a uma necessidade de 300, 600 ou 4 000. Uma classe B podia ser muito grande. Um conjunto de classes C podia ser mais próximo em volume de endereços, mas mais difícil de gerenciar e, antes de uma agregação eficaz, mais custoso para o sistema de roteamento global.

A sub-rede ajudava dentro de uma rede por classes existente. A RFC 950, uma especificação a caminho da padronização de agosto de 1985, definia uma máscara de endereço que dividia o campo de endereço local em partes sub-rede e host. Uma organização podia usar um único número de rede reconhecido externamente em várias sub-redes internas, em vez de anunciar cada cabo interno como uma rede independente. Isso não permitia por si só que um registro emitisse comprimentos de prefixo roteados globalmente arbitrários para uma Internet cujos mecanismos entre domínios ainda se baseavam na interpretação de classes.RFC 950, agosto de 1985, seção 2.1, páginas 4–6

A segunda pressão vinha da tabela de encaminhamento. Substituir uma antiga atribuição de classe B por 16 redes classe C anunciadas separadamente podia preservar um número de rede classe B enquanto adicionava 16 entradas de roteamento onde a agregação não estava disponível. A conservação de endereços e a conservação de roteamento podiam, portanto, ir em direções opostas.

A RFC 1519, publicada como padrão proposto em setembro de 1993, descrevia três problemas: o rápido esgotamento dos números de rede classe B, o crescimento da tabela de roteamento além das capacidades dos softwares e roteadores disponíveis, e o esgotamento futuro do espaço de 32 bits. Sua estratégia imediata era o CIDR: atribuir blocos contíguos de tamanho mais apropriado, alinhar a distribuição com a topologia e anunciar agregados quando o suporte dos protocolos e a conectividade permitissem.RFC 1519, status e seções 1–3, páginas 1–9

Seu argumento quantitativo requer tanto a tabela exata quanto o texto arredondado.

A tabela I, proveniente da MERIT, reportava 4 526 rotas anunciadas em janeiro de 1992 e 8 561 em dezembro de 1992. A seção 3.3.2 descrevia, em vez disso, a base de dados de roteamento NSFNET de janeiro como contendo "cerca de 4 700" entradas e a de dezembro como contendo 8 500. Ela indicava que a tabela histórica havia dobrado em média a cada dez meses entre 1988 e 1991 e publicava uma projeção de cerca de 30 000 entradas dois anos após a referência de janeiro de 1992.RFC 1519, tabela I e seção 3.3.2, páginas 7–9

Essa projeção não decorre das entradas arredondadas indicadas:

[4,700\times 2^{24/10}=24,806.75]

Usando a observação exata da tabela I de janeiro, obtém-se:

[4,526\times 2^{24/10}=23,888.37]

Nenhum desses resultados é cerca de 30 000 em arredondamento comum. O artigo só pode reter 30 000 como a projeção publicada e não reconciliada dos autores da RFC. A fonte não explica a diferença de cerca de 5 193 entradas entre 30 000 e o resultado obtido com as entradas arredondadas. Seria inadequado inventar uma referência, um intervalo de crescimento ou um ajuste oculto diferentes para preencher a lacuna.

A comparação de dezembro é mais direta. A unidade observada da tabela I era de 8 561 rotas anunciadas em dezembro de 1992. A seção 3.3.2 arredondava esse número para 8 500 e o comparava a mais de 9 400 previstos por uma curva anterior. Os autores diziam não poder determinar se a observação mais baixa representava uma mudança significativa no crescimento. Eram observações e previsões no contexto MERIT/NSFNET, não um censo de todos os roteadores nem um limite físico no qual a Internet teria falhado.

A RFC também examinava o efeito da emissão de quatro a 16 rotas classe C onde uma classe B poderia ter sido usada anteriormente. Ela projetava condicionalmente que a tabela de roteamento poderia ultrapassar 10 000 entradas em seis meses e 20 000 em um ano. Eram resultados de cenários baseados em redes classe C anunciadas separadamente, e não resultados observados. A agregação destinava-se a impedir precisamente essa multiplicação.

A lógica técnica era sólida. Se os clientes conectados por um mesmo provedor recebessem subconjuntos contíguos do bloco desse provedor, o provedor poderia anunciar uma única rota menos específica. Dez blocos de clientes roteados independentemente poderiam exigir dez entradas visíveis globalmente; dez blocos de clientes alinhados com a topologia poderiam, sujeitos a exceções e operação correta, ser cobertos por um único agregado. A economia exata dependia de multihoming, política de roteamento, falhas, filtros e da necessidade de ainda propagar rotas mais específicas.

A transição não era automática. A RFC 1338, uma proposta informativa publicada em junho de 1992 e posteriormente tornada obsoleta pela RFC 1519, advertia que o novo plano de endereçamento e modificações nos protocolos de roteamento entre domínios eram necessários. Ela indicava que as tabelas de roteamento poderiam crescer muito rapidamente no intervalo entre a implantação das alocações orientadas à topologia e a implantação de protocolos compatíveis.RFC 1338, junho de 1992, seção 2.1, página 4

O BGP-4 fornecia uma especificação para o transporte de prefixos sem classe e agregação de rotas, mas o status de publicação não deve ser confundido com implantação. A RFC 1654 era uma especificação BGP-4 a caminho da padronização em julho de 1994. A RFC 1771, também a caminho da padronização, a substituiu em março de 1995 e descrevia o suporte para prefixos IP, a remoção da noção de classe de rede no BGP, e a agregação de rotas e caminhos AS.RFC 1654, julho de 1994, status e seções 1–2, páginas 1–2;RFC 1771, março de 1995, status e seções 1–2, páginas 1–2

Essas publicações estabelecem o status de especificação e a capacidade documentada. Não estabelecem quantos roteadores executavam BGP-4 em uma dada data, quais redes trocavam rotas sem classe, que parte da tabela era agregada, ou se a adoção era universal em 1998. Sem uma série nomeada de instantâneos de roteamento, uma data de observação, uma população e um ponto de observação, nenhuma taxa de implantação numérica ou afirmação "estabelecido em 1998" é justificada.

A regra de previsão distribuía a incerteza

A regra da classe B da RFC 1466 expõe mais claramente a escolha institucional. Seus critérios indicados exigiam mais de 32 sub-redesemais de 4 096 hosts. O solicitante também devia demonstrar por que um bloco de classes C era desarrazoado e fornecer os números previstos de hosts e sub-redes para os 24 meses seguintes. Se o plano não justificasse uma classe B, o resultado indicado era um bloco de classes C. Um solicitante que não satisfizesse os critérios numéricos mas não pudesse usar classes C podia apresentar um argumento técnico. O documento qualificava esses limites de critérios sugeridos, em vez de invariante de protocolo.RFC 1466, seção 4.2.1, páginas 6–7

O objetivo técnico imediato era a conservação dos números de rede classe B. Segundo a convenção da época, uma classe B expunha 65 534 identificadores de host comuns. Atribuir essa unidade a uma rede com necessidade muito menor podia bloquear grande parte de sua capacidade. O plano de sub-rede verificava se o solicitante precisava da topologia que uma classe B podia acomodar, em vez de simplesmente preferir sua conveniência.

A RFC 1466 reconhecia o ônus. Ela indicava que as restrições sobre alocações de classe B poderiam obrigar algumas organizações a dedicar recursos adicionais ao uso de vários números de rede classe C. O documento considerava esse custo como lamentável, mas necessário para prosseguir a conservação. É uma evidência excepcionalmente direta da incidência de custos: a recomendação do autor escolheu uma regra de conservação e identificou como consequência despesas técnicas adicionais para os solicitantes afetados.RFC 1466, seção 4.2, página 6

O horizonte de 24 meses não deixava de ser um parâmetro. A RFC informativa documentava por que as previsões eram necessárias, mas não demonstrava que 24 meses minimizavam de forma única o desperdício total de endereços, o custo de processamento, os prazos ou o erro de previsão. Um teste de 12, 18 ou 36 meses seria uma variante construída pelo analista, a menos que uma proposta direta da época fosse produzida. Tais variações são administrativamente concebíveis, pois o mesmo solicitante poderia submeter as mesmas categorias de evidências técnicas em um horizonte diferente.

Seus desempenhos práticos permanecem desconhecidos: um horizonte mais curto reduziria a exposição a um crescimento otimista, mas aumentaria as solicitações repetidas, enquanto um horizonte mais longo poderia reduzir a frequência das transações ao preço de um erro de previsão maior.

A alocação sem classe era uma alternativa mais fundada tecnicamente em 1993, mas apenas dentro de certos limites. A RFC 1338 havia proposto blocos de provedores contíguos em junho de 1992, e a RFC 1519 especificava a estratégia de atribuição e agregação CIDR em setembro de 1993. Suas próprias advertências mostram as hipóteses requeridas: os registros deviam alocar em fronteiras adequadas, os provedores deviam manter blocos alinhados com a topologia, e os protocolos entre domínios e os roteadores deviam suportar pares rede-máscara arbitrários.

Antes que essas condições fossem suficientemente implementadas, a emissão de blocos mais finos podia multiplicar as rotas em vez de reduzi-las.

A RFC 2050 modificou o desenho das previsões em novembro de 1996. Ela separava as alocações para ISPs das atribuições para empresas finais. A seção 2.1 indicava que novos ISPs receberiam uma alocação mínima baseada nas necessidades imediatas. Alocações posteriores poderiam aumentar após o ISP fornecer uma verificação do uso, e o espaço adicional destinava-se a cobrir cerca de três meses de atribuições a jusante. A clientela projetada era considerada ter pouco efeito; as necessidades demonstradas prevaleciam.RFC 2050, BCP 12, novembro de 1996, seção 2.1, páginas 4–5

Os famosos números de 25 e 50 por cento se encontravam em outro lugar. Estavam na seção 3.1, no quadro das atribuições para empresas finais: uma taxa de utilização imediata de 25 por cento e uma taxa de utilização de 50 por cento dentro de um ano. A seção 3.6 definia o numerador como o número de hosts conectados à rede e o denominador como o número total de hosts possíveis nessa rede. O critério de um ano significava, portanto, que se esperava que os hosts conectados atingissem pelo menos 50 por cento da população possível de hosts da rede nesse horizonte. Não se tratava de um ratio clientes/endereços, endereços atribuídos/tamanho da alocação, interfaces/endereços, ou atribuições a jusante/alocação ISP.RFC 2050, seções 3.1 e 3.6, páginas 7 e 9

Essa distinção altera a análise institucional. As empresas finais enfrentavam um teste de uso baseado em hosts conectados versus hosts possíveis em sua rede proposta. Os ISPs enfrentavam um início progressivo, uso a jusante verificado e uma quantidade de reabastecimento destinada a cobrir cerca de três meses de atribuições adicionais. Combiná-los criaria uma métrica comum fictícia.

Ambos os desenhos colocavam a incerteza das previsões em algum lugar. Uma atribuição inicial mais longa expunha o pool comum se a demanda não se materializasse. Uma atribuição inicial menor aumentava a importância da reatividade do registro e da capacidade do solicitante de documentar um crescimento repetido. As RFCs estabelecem as regras escolhidas e seus objetivos declarados. Não fornecem distribuições dos prazos de processamento, dos montantes iniciais solicitados, dos históricos de revisão, nem a prova de que uma classe de solicitantes sofreu sistematicamente mais atrasos.

A hierarquia transformou a topologia em dependência

A RFC 1466 propunha dividir porções do espaço dos números de classe C em grandes blocos geográficos e delegar a responsabilidade principal de alocação a registros regionais qualificados. Ela descrevia essa divisão como "essencialmente uma divisão administrativa" destinada a apoiar o registro distribuído. Privilegiava um registro regional único nesse nível, esperava que a organização fosse reconhecida e dotada de recursos suficientes, e exigia um compromisso com as diretrizes da IANA e do registro central da Internet. O registro central permanecia disponível para atender um subscritor se necessário, embora pudesse encaminhá-lo ao órgão regional.RFC 1466, seções 2, 3 e 4.3, páginas 2–4 e 7

O plano geral ligava a administração distribuída à agregação potencial. Os blocos geográficos podiam reduzir a carga de trabalho central e permitir resumos grosseiros quando a geografia e a topologia coincidiam. Nenhuma dessas relações era garantida. Um continente não estava codificado no cabeçalho IPv4, e a topologia física ou dos provedores não seguia necessariamente uma fronteira regional.

A escolha de um registro regional reconhecido único concentrava a autoridade de interpretação sobre as alocações locais, as evidências e as exceções. Uma base de dados compartilhada com registros que se sobrepõem, ou uma escolha geral do solicitante entre os decisores centrais e regionais, seria uma alternativa analítica, em vez de uma proposta documentada da época nas fontes aqui utilizadas. Sua viabilidade pressuporia coordenação rápida de bases de dados, verificações fiáveis de unicidade, regras de alocação comuns e um meio de impedir atribuições concorrentes. Essas hipóteses eram administrativamente exigentes em 1993.

A alternativa é útil para situar a autoridade, não para afirmar que registros sobrepostos teriam dado melhores resultados.

A RFC 1519 deslocou a hierarquia para a topologia dos provedores. Ela recomendava que a maioria, senão todos, os números de rede fossem distribuídos por intermédio dos provedores de serviços. Sua lógica técnica era direta: endereços retirados do bloco de um provedor podiam ser representados pelo agregado desse provedor, enquanto blocos situados independentemente exigiam frequentemente rotas mais específicas. O documento também argumentava que a alocação distribuída reduzia a carga burocrática sobre as autoridades centrais de numeração.RFC 1519, seções 2.2 e 3, páginas 5–8

A RFC 2050 descrevia um sistema de registros a três níveis: a IANA, os registros Internet regionais e os registros Internet locais. No quadro dos ISPs, um ISP trocando rotas em vários locais sem roteamento padrão podia solicitar espaço diretamente ao seu registro regional. Dizia-se aos outros ISPs para solicitarem espaço a um provedor upstream. O acesso regional direto estava associado a multihoming ou conexão a um ponto de troca neutro importante, que a RFC definia como conectando quatro ISPs não relacionados ou mais.RFC 2050, seções 1.1 e 2.1, páginas 3–4

A mesma seção encorajava os provedores a tratar as atribuições aos clientes como empréstimos durante a duração da conectividade. Quando um cliente mudava de provedor, ela recomendava a devolução dos endereços antigos e a renumeração no espaço do novo provedor, com um prazo de transição suficiente antes da reutilização. Era uma estratégia de roteamento com uma consequência em termos de custo de mudança. O espaço proveniente do provedor melhorava as possibilidades de agregação; a continuidade dos endereços do cliente tornava-se dependente da relação com o provedor.

Os custos já eram reconhecidos. A RFC 1900, uma declaração informativa do Internet Architecture Board em fevereiro de 1996, indicava que as organizações que não renumeração após mudar de provedor poderiam enfrentar conectividade limitada, custos adicionais para suportar a carga de roteamento resultante, ou ambos. Seu título,Renumbering Needs Work, resumia o estado da técnica. Ela pedia o desenvolvimento e implantação de mecanismos para facilitar as mudanças; não relatava que a renumeração se tornara barata ou rotineira.RFC 1900, fevereiro de 1996, seção 1, páginas 2–3

Os decisores e responsáveis pela implementação nomeados eram os autores das RFCs, as autoridades da IANA e dos registros, os registros regionais e locais, os provedores que atribuíam espaço e as redes de trânsito que aceitavam ou filtravam rotas. A alternativa possível na época não era um endereçamento portátil ilimitado. Era um equilíbrio diferente: mais alocações diretas reduziriam a dependência de alguns clientes à renumeração, mas, na ausência de uma agregação fiável ou de uma coordenação sobre a aceitação de rotas, poderiam adicionar prefixos visíveis globalmente. Os documentos conservados provam a direção da arbitragem.

Não quantificam quantos clientes renumeração, quantos conservaram antigas rotas, o que pagaram, ou com que constância os provedores fizeram cumprir a devolução.

O poder de auditoria existia no papel; sua prática permanece não medida

A terceira escolha institucional dizia respeito à verificação e às consequências.

A RFC 1466 permitia ao registro central da Internet receber os planos contábeis e técnicos das alocações regionais delegadas e verificar a coerência desses planos com as diretrizes. As exceções aos critérios de dimensionamento da classe C deviam ser decididas caso a caso. O documento não fornecia um registro de exceções, um prazo de resposta padrão, um ônus da prova publicado ou um examinador independente.RFC 1466, seções 4.2.2 e 4.3, páginas 7–8

A RFC 2050 descrevia um conjunto de evidências mais extenso. Um registro podia exigir máscaras de sub-rede, contagens de hosts, topologia, planos de roteamento, cronogramas de implantação, as atribuições anteriores e corroborações. O espaço previamente detido por divisões ou filiais sob uma mesma entidade mãe podia ser considerado ao nível da empresa. As solicitações eram tratadas caso a caso, com a eficiência do roteamento entre as considerações pertinentes.RFC 2050, seções 3.2–3.5, páginas 8–9

A seção 4 indicava que todas as solicitações de endereços estavam sujeitas a auditoria e verificação por qualquer meio que o registro regional julgasse apropriado. Se se verificasse que uma atribuição se baseava em informações falsas, o registro podia invalidar a solicitação e devolver os endereços atribuídos ao pool livre. A seção 3.1 especificava separadamente que um endereço permanecia válido enquanto os critérios de qualificação continuassem a ser cumpridos e reservava um poder de invalidação quando a necessidade já não existisse. A recomendação de devolução da seção 2.1 aplicava-se aos endereços de clientes provenientes do provedor quando a conectividade terminava. Eram poderes ligados mas distintos: a invalidação por informação falsa, a revisão da persistência da necessidade e a devolução na mudança de provedor.RFC 2050, seções 2.1, 3.1 e 4, páginas 4–5, 7 e 10

O texto previa também uma revisão hierárquica. A seção 6 permitia a uma organização insatisfeita com o registro de atribuição recorrer ao registro pai. A documentação pertinente devia ser disponibilizada, e um recurso adicional podia subir a cadeia até a IANA. Cada registro devia documentar seu procedimento de recurso. O examinador permanecia na mesma hierarquia de registros; a RFC não criava um tribunal externo.RFC 2050, seção 6, página 11

Essas disposições autorizavam a aplicação e a revisão. Não demonstram a prática. Nenhum ficheiro citado estabelece a frequência das auditorias, os métodos utilizados, se os solicitantes recebiam um pré-aviso ou uma possibilidade de regularização, como o erro de previsão era distinguido de uma falsa declaração, a frequência das devoluções de endereços, ou se um recurso alterou um resultado. O texto não pode demonstrar a consistência entre registros ou em casos individuais.

Várias variantes procedimentais são concebíveis com a tecnologia de 1996, pois modificam a administração em vez dos formatos de pacotes: motivação escrita das exceções, protocolo de auditoria definido, período de pré-aviso e regularização, estatísticas anonimizadas, ou revisão por responsáveis exteriores à cadeia de decisão inicial. São parâmetros construídos pelo analista, a menos que uma proposta datada seja produzida. Exigiriam pessoal, manutenção de registos, controlos de confidencialidade e uma autoridade acordada. Seus custos e efeitos não podem ser estimados apenas a partir da RFC.

A escolha institucional era, portanto, real mas limitada. A RFC 2050 dava aos registros regionais um poder discricionário sobre a verificação e as consequências enunciadas, colocando ao mesmo tempo a revisão na cadeia parental. Esse desenho podia dissuadir falsas declarações e preservar os registros de endereços. Também concentrava a autoridade de investigação, exceção e sanção. As evidências de que essa autoridade existia são sólidas; as evidências sobre sua invocação e efeitos distributivos estão ausentes.

O arquivo RIPE prova menos do que um arquivo de atribuição faria

O episódio RIPE fornece a prova de um funcionamento delegado, mas não de uma decisão de alocação completa.

O documento RIPE-062,RIPE NCC Internet Numbers Registration Procedures, versão 0.5 de julho de 1992, figura no anexo A do primeiro relatório trimestral do RIPE NCC. Indicava que o RIPE NCC atuava desde 1 de maio de 1992 como registro delegado para os números de rede Internet europeus. Seu procedimento consistia em fornecer números aos provedores de serviços e aos organismos de coordenação nacionais ou locais, em vez de diretamente a organizações individuais. Permitia aos provedores de serviços solicitar números de rede classe B um a um e exigia uma justificativa baseada no tamanho da organização, na rede existente, no crescimento previsto e na impossibilidade de usar um bloco classe C.RIPE-062, versão 0.5, julho de 1992, página 25 e seguintes

A seção 3 da RFC 1466 posteriormente registrou dois fatos mais restritos. O RIPE NCC já havia recebido o intervalo de números de rede classe C de 193.0.0 a 193.255.255 antes da adoção da proposta da RFC, e havia concordado em alocar dentro desse intervalo de acordo com as diretrizes da RFC 1466.RFC 1466, seção 3, página 3

O intervalo contém 2^{16} = 65 536 números de rede classe C de tamanho/24. Expresso na forma do intervalo CIDR posterior 193.0.0.0/8, ele cobre 2^{32-8} = 16 777 216 valores de endereço nominais. O primeiro número conta unidades de número de rede classe C; o segundo conta os valores binários cobertos pelo intervalo. Nenhum dos dois mede hosts conectados, atribuições a jusante, anúncios, uso ou a quantidade solicitada pelo RIPE NCC.

Os documentos conservados não fornecem a solicitação subjacente, um ato de atribuição formal, uma nota de decisão, os tamanhos de bloco alternativos considerados, as condições negociadas ou uma data de atribuição exata. RIPE-062 prova um procedimento delegado. A RFC 1466 prova a posse anterior do bloco 193.* e o acordo para usar as novas diretrizes. A administração distribuída e a agregação potencial eram objetivos do plano político geral; não se pode afirmar que constituem o motivo documentado ou a condição negociada dessa atribuição particular.

O arquivo também não contém um arquivo de recurso ou revisão sobre a delegação. Permite concluir, ao nível do registro, que a delegação funcionava em 1992. Não permite tirar uma conclusão ao nível dos solicitantes sobre recusas, desigualdades de tratamento, atrasos ou incidência de um limite.

As respostas técnicas chegaram por etapas

O período não ofereceu um substituto completo ao racionamento. Ofereceu respostas parciais com diferentes status, pré-requisitos e transferências de custos.

O espaço privado ilustra a diferença entre especificação e substituição. A RFC 1918, BCP 5 de fevereiro de 1996, reservava três blocos para redes privadas. Exigia de uma empresa que determinasse quais hosts não precisavam de conectividade externa ao nível da rede. A passagem de um host do status privado para público implicava mudar seu endereço IP, as entradas DNS correspondentes e os arquivos de configuração nos outros hosts que faziam referência ao endereço. As informações de roteamento privado não deviam propagar-se para além das fronteiras da empresa, e as referências DNS privadas exigiam confinamento.RFC 1918, fevereiro de 1996, seções 2–5, páginas 3–7

O NAT era mais do que um conceito em maio de 1994, mas menos do que uma solução universal comprovada. A RFC 1631 era informativa e descrevia um desenho preliminar. A seção 3 explicava que as aplicações transportando um endereço IP em seus dados podiam falhar a menos que o tradutor reconhecesse e reescrevesse o conteúdo; a criptografia podia tornar isso impossível. A seção 4 identificava implementações experimentais no software KA9Q e em um roteador Cray Communications, testadas com Telnet e FTP, e indicava que os protótipos só demonstravam transparência dentro dos limites enunciados pelo artigo.RFC 1631, maio de 1994, seções 3 e 4, páginas 6–9

O IPv6 mudou o denominador arquitetônico. A RFC 1883, uma especificação a caminho da padronização publicada em dezembro de 1995, fez passar o tamanho do endereço IP de 32 para 128 bits. Ela não substituiu os hosts, roteadores, aplicações ou procedimentos operacionais IPv4 instalados à sua publicação. Para um registro tratando uma solicitação IPv4 em 1996, IPv6 era um sucessor especificado, e não a prova de que o problema imediato de alocação IPv4 havia desaparecido.RFC 1883, dezembro de 1995, status e seção 1, páginas 1 e 3

A recuperação também conheceu etapas. A RFC 2050 recomendava a devolução dos endereços provenientes do provedor após o fim da conectividade e autorizava a invalidação em circunstâncias especificadas. Não continha um conjunto de dados sobre os blocos recuperados e não estabelecia com que facilidade as redes operacionais podiam cedê-los. A recuperação era um mecanismo autorizado, não uma resposta medida da oferta.

A melhoria do hardware permanecia uma possibilidade condicional. A RFC 2050 indicava que as restrições de endereçamento refletiam a tecnologia dos roteadores, as práticas de atribuição e a história arquitetônica. O documento reportava uma conclusão de seus autores, do grupo de trabalho da IETF encarregado da revisão e do IESG de que nenhuma outra tecnologia implantável na época superava essas limitações, permitindo ao mesmo tempo um reexame se os roteadores posteriormente gerenciassem tabelas maiores e mais dinâmicas ou se a agregação se tornasse possível por outros meios. Trata-se de uma avaliação institucional contemporânea da tecnologia, não de uma referência para cada roteador e não de prova de que os parâmetros de previsão, auditoria e recurso que a acompanhavam eram institucionalmente únicos.RFC 2050, introdução, página 2

A RFC 2050 representava a prática sem receber aprovação política

O papel institucional importa, pois "a IETF decidiu" amalgamaria vários atos diferentes.

A RFC 2050 era o BCP 12, publicado em novembro de 1996, e tinha como autores Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg e Jon Postel. Seu resumo descrevia as políticas então usadas pelos registros regionais para implementar as diretrizes elaboradas pela IANA e indicava que as regras permaneciam sujeitas a revisão.RFC 2050, página de título, resumo e introdução, páginas 1–2

A nota do IESG era deliberadamente mais estreita do que uma aprovação. Ao aprovar o documento como Boa Prática Atual, o IESG declarou que estimava que a política representava fielmente a prática atual dos registros. Recusou expressamente aprovar ou recomendar a política e previu um reexame à luz das discussões posteriores do grupo de trabalho. A aprovação da exatidão descritiva, a redação do texto, a elaboração das diretrizes dos registros, a implementação pelos registros e os conselhos de um grupo de trabalho eram papéis institucionais distintos.

A RFC apresentava a conservação, a roteabilidade e o registro como três objetivos. Reconhecia também os conflitos entre esses objetivos e com os interesses dos usuários finais e dos provedores. A conservação favorecia uma adequação estreita entre a oferta e a necessidade demonstrada. A roteabilidade favorecia uma distribuição hierárquica sensível à topologia. O registro favorecia levantamentos precisos das atribuições.

Uma atribuição otimizada para um objetivo podia dar maus resultados em relação a outro: uma pequena alocação direta podia conservar o volume de endereços mas adicionar uma rota; um bloco de provedor podia agregar bem mas impor uma renumeração; uma verificação aprofundada podia melhorar os registros mas aumentar o custo das transações.

Esse reconhecimento é a contra-evidência interna mais sólida contra uma narrativa simplista de burocracia arbitrária. Os autores reconheciam um problema técnico com múltiplos objetivos e pediam um julgamento prudente. Os documentos justificam levar esse problema a sério. Não transformam cada limite ou remédio institucional em uma consequência necessária do cabeçalho.

A melhor defesa técnica sobrevive à auditoria

Um julgamento justo começa pelo perigo de uma sobrealocação irreversível. Uma vez que os endereços estavam integrados nas configurações dos roteadores, DNS, regras de acesso, parâmetros das aplicações, sistemas dos clientes e documentação, a recuperação tornava-se cara. Não se podia supor que uma grande atribuição otimista seria devolvida corretamente após o fracasso das previsões. Alocações iniciais menores limitavam essa exposição.

O início progressivo respondia à assimetria de informação. Um novo provedor conhecia melhor seu plano de negócios do que um registro, mas nenhuma das partes podia observar a demanda futura dos clientes. O processo da RFC 2050 usava as necessidades imediatas, as atribuições a jusante verificadas e as solicitações repetidas para substituir parte da incerteza das previsões por um histórico administrativo observado. Isso podia conservar o pool e melhorar a exatidão do registro.

A alocação sem classe corrigia um desajuste de tamanho severo. A escolha entre 254 e 65 534 identificadores comuns era mal adaptada a redes de tamanho médio. Prefixos contíguos podiam aproximar-se mais da necessidade do que uma classe B nativa, evitando ao mesmo tempo uma coleção arbitrária de classes C não relacionadas.

A agregação dizia respeito a um recurso compartilhado distinto. As observações de rotas de janeiro e dezembro de 1992, apesar da previsão não reconciliada a dois anos da RFC, mostravam um crescimento rápido em uma tabela concreta proveniente da MERIT. Os agregados dos provedores podiam reduzir o número de destinos transportados pelos roteadores sem defeito. O ganho dependia da topologia, dos softwares e da cooperação, mas era tecnicamente substancial.

A hierarquia dos provedores decorria dessa lógica de agregação. Se um cliente usasse endereços retirados do bloco de seu provedor, o resto da Internet podia frequentemente apoiar-se no agregado do provedor. O espaço portátil reduzia a dependência de um único provedor, mas podia exigir uma rota global distinta. A rede em sentido amplo, e não apenas o cliente e o registro, suportava o estado associado a essa rota.

A documentação servia também a mais do que a conservação. Os registros de atribuição facilitavam a contactabilidade, o DNS reverso, a evitação de atribuições duplicadas e a verificação do uso a jusante. Um solicitante solicitando capacidade adicional possuía informações que o registro não tinha. Um certo exame era, portanto, racional, mesmo que cada detalhe procedimental pudesse ser contestado.

O poder de exceção podia impedir que uma regra numérica fosse contra seu objetivo técnico. Multihoming, topologia incomum, limitações de equipamento ou uma necessidade direta importante podiam tornar um bloco padrão inadequado. Um tratamento caso a caso permitia ao registro levar em conta circunstâncias que uma simples percentagem de hosts não podia captar.

Essas considerações estabelecem argumentos técnicos sérios a favor da conservação, agregação, registro, início progressivo e julgamento prudente. Um sistema uniforme de grandes atribuições incondicionais poderia ter consumido mais rapidamente as unidades por classes que se tornaram raras. Um sistema uniforme de pequenas atribuições roteadas independentemente poderia ter expandido as tabelas sem defeito. Um sistema sem regras teria tornado mais difíceis as atribuições duplicadas e a avaliação comparável das necessidades.

Essa defesa não estabelece a unicidade institucional. Não mostra que o horizonte de 24 meses era o horizonte de previsão ótimo, que o período de reabastecimento dos ISPs da RFC 2050 minimizava o custo combinado do registro e do solicitante, que um registro regional único era a única estrutura viável, ou que o recurso hierárquico era superior a uma revisão parcialmente independente. As evidências técnicas apoiam os objetivos e alguns mecanismos. Dados sobre solicitantes, roteamento, pessoal e resultados seriam necessários para classificar os desenhos completos.

Uma comparação limitada a 1996 situa a autoridade, não os resultados

Um contrafatual útil pode ser fixado em novembro de 1996, quando a RFC 2050 foi publicada. Mantenhamos constantes os campos IPv4 de 32 bits, os vestígios instalados capazes de sem classe e por classes da época, as especificações BGP-4 então disponíveis, os recursos limitados dos roteadores, uma demanda incerta, renumeração custosa e a ausência de conversão universal imediata para IPv6. Não suponhamos uma implantação universal do BGP-4, do NAT ou dos endereços privados, pois as especificações citadas não medem a adoção.

Comecemos pela base documentada: alocação orientada a provedor, início progressivo para novos ISPs, capacidade adicional destinada a cobrir cerca de três meses de atribuições, testes de uso para empresas finais, exceções caso a caso, autoridade de auditoria do registro e recurso ao registro pai.

Façamos variar analiticamente três parâmetros institucionais.

A primeira variação modifica o intervalo de reabastecimento. Um ISP poderia receber o suficiente para cobrir seis meses em vez de cerca de três meses. Não se trata de uma proposta histórica documentada. É administrativamente plausível apenas na hipótese de que o registro pai pudesse dimensionar um bloco contíguo maior sem modificar os formatos de pacotes e que as previsões dos provedores fossem suficientemente credíveis. O efeito provável sobre a autoridade é uma redução do número de transações com o registro e uma menor dependência de um reabastecimento rápido.

O risco provável para a conservação é uma capacidade não utilizada maior quando o crescimento não se materializa. Sem históricos de solicitações, erros de previsão e dados de atribuição, nenhuma dessas amplitudes pode ser estimada.

A segunda variação mantém o início progressivo de três meses mas publica antecipadamente faixas de alocação e um calendário tipo de evidências. Esta também é construída pelo analista. Supõe que os registros dispunham do pessoal e dos sistemas de registro necessários para manter regras públicas protegendo ao mesmo tempo informações sensíveis dos clientes. Poderia reduzir a incerteza quanto à documentação e facilitar a comparação de casos similares, mas poderia incentivar uma apresentação estratégica em torno dos limites publicados e reduzir a flexibilidade para redes atípicas.

A terceira variação mantém a hierarquia técnica mas modifica a revisão. As decisões iniciais de alocação e auditoria permanecem ao encargo do registro; um comitê não responsável pela decisão inicial examina as exceções escritas e as invalidações. Nenhuma fonte direta mostra que tal comitê tenha sido proposto em 1996. A variação é administrativamente concebível apenas se o sistema de registros pudesse nomear examinadores, compartilhar evidências confidenciais sob garantias e financiar um procedimento adicional. Desloca parte da autoridade de revisão sem adicionar bits de endereço nem modificar a agregação de rotas.

Uma variação mais ampla de alocação direta também pode ser descrita, mas suas hipóteses são mais pesadas. Pequenas organizações mono-hospedadas poderiam receber blocos regionais diretos e mantê-los ao mudar de provedor, sujeitas a um prefixo mínimo acordado aceito globalmente. Esse mínimo, o acordo sobre a aceitação de rotas e a capacidade administrativa são todos parâmetros analíticos, e não regras históricas recuperadas. Esse desenho poderia reduzir a renumeração dos clientes mas aumentar as rotas visíveis independentemente.

O arquivo citado não prova que os provedores de trânsito teriam aceitado essas rotas ou que os roteadores da época poderiam ter absorvido a tabela resultante.

A comparação revela onde se situam os custos e o poder discricionário. Um reabastecimento curto faz pesar mais riscos de transação e calendário sobre o ISP, limitando ao mesmo tempo a exposição do pool ao fracasso das previsões. Atribuições iniciais maiores invertem parte dessa incidência. Faixas publicadas trocam o poder discricionário pela visibilidade das regras. Um examinador distinto desloca parte do poder corretivo para fora da cadeia de decisão inicial. Uma portabilidade mais ampla transfere a continuidade para o cliente e o custo do estado de roteamento para a rede em sentido amplo.

Não pode mostrar qual variação era realizável em grande escala, quantos endereços cada uma consumiria, quantas rotas cada uma geraria, ou qual melhoraria o bem-estar. Uma calibragem exigiria as solicitações dos solicitantes, os montantes concedidos e recusados, os prazos de processamento, os erros de previsão, as políticas de roteamento dos provedores, a capacidade dos roteadores, os custos de pessoal, os resultados das renumerações, os arquivos de auditoria e observações comparáveis do uso. Esses elementos estão ausentes.

A conclusão baseada nas evidências é, portanto, mais estreita: a RFC 2050 não demonstrou por si mesma a unicidade institucional de seu desenho. Ela documentava a prática dos registros da época, enunciava um julgamento tecnológico contemporâneo e descrevia regras destinadas a conciliar objetivos concorrentes. As variações analíticas identificam decisões integradas nessas regras. Não provam um desempenho superior.

Quatro conclusões, com diferentes níveis de confiança

O fato arquitetônico é o mais sólido. A RFC 791 fixou cada campo de origem e destino IPv4 em 32 bits. O resultado foram 2^{32} valores nominais por campo, não um espaço de nomes ilimitado e não 4 294 967 296 hosts públicos atribuíveis.

As consequências ligadas às classes e ao roteamento são igualmente bem apoiadas. Os grandes desvios entre as capacidades de hosts comuns da classe C e da classe B tornavam as atribuições de tamanho médio ineficientes. Várias classes C podiam conservar um número de rede classe B enquanto adicionavam rotas. A tabela MERIT da RFC 1519 documentava 4 526 rotas anunciadas em janeiro de 1992 e 8 561 em dezembro de 1992.

Sua projeção de cerca de 30 000 a dois anos não pode ser reproduzida a partir da fórmula de duplicação indicada, mas a preocupação subjacente com o crescimento das rotas e a granularidade por classes não dependia unicamente desse erro aritmético.

As escolhas administrativas são identificáveis. A RFC informativa de Gerich recomendava previsões de 24 meses, limites, divisões geográficas, auditorias e exceções caso a caso. Os autores do CIDR ligaram a alocação à topologia dos provedores e à agregação sem classe. Hubbard, Kosters, Conrad, Karrenberg e Postel documentaram o início progressivo, a hierarquia, os testes de uso baseados em hosts conectados, a autoridade de auditoria, invalidação, devolução e recurso hierárquico do BCP 12. A IANA, os registros regionais e locais, os provedores e as redes de trânsito ocupavam diferentes papéis de implementação.

O IESG aceitou a RFC 2050 como uma representação fiel da prática atual, recusando ao mesmo tempo aprovar a política.

Os resultados completos permanecem não resolvidos. Os registros de alocação não contêm o denominador das solicitações. As fontes citadas não revelam todas as recusas, reduções, retiradas, conselhos informais, atrasos, regularizações de auditoria, devoluções, exceções ou resultados de recurso. Os dados posteriores dos registros contêm datas legadas e reconstituídas. Nenhum conjunto de dados da época citado mede a implantação universal do BGP-4, a ocupação completa dos endereços, o ônus comparável dos solicitantes ou a contribuição causal de um único limite para a conservação.

O título pode suportar essas distinções. O campo finito era técnico. A alocação por classes e o estado dos roteadores criaram uma real pressão técnica. O regime de racionamento era político no sentido restrito, baseado nas evidências, de que instituições identificáveis escolheram os horizontes de previsão, os níveis de alocação, as hierarquias, os testes de prova, a autoridade de exceção e os recursos no quadro de restrições que não impunham uma constituição administrativa completa e única.

A necessidade técnica justificava a ação coletiva. Não determinava por si só quem definiria a necessidade, deteria evidências confidenciais, concederia exceções, imporia consequências ou decidiria o recurso final.