A era dos endereços por classes e o nascimento da escassez administrativa

Resumo

• Uma rede que necessitava de 300 endereços de host comuns excedia em 46 endereços a capacidade prática de 254 de uma rede de classe C. A classe nativa seguinte oferecia 65.534 endereços de host comuns, enquanto duas classes C ofereciam 508 ao possível custo de uma rota adicional e de uma coordenação acrescida. A geometria por classes fazia, portanto, da alocação uma escolha entre custos diferentes, em vez de uma simples leitura da demanda por hosts.
• Três instantâneos contemporâneos mostram que as redes de classe C dominavam em número de unidades de números de rede atribuídos, enquanto as alocações de classe A dominavam em capacidade de endereços representada. Em janeiro de 1983, 31 alocações de classe A representavam 99,648% dos valores numéricos de endereços cobertos pelos totais publicados; 1.042 classes C representavam 0,051%.
• O material preservado não fornece uma amostra pareada das primeiras solicitações, recusas e decisões. Não pode estabelecer um efeito geral de precursor, um acesso desigual dos solicitantes ou os critérios utilizados em uma decisão de classe precoce particular. Ele sustenta uma conclusão mais estreita: alocações duradouras feitas antes que critérios posteriores se tornassem explícitos podiam criar uma opção vantajosa plausível dependente do caminho.
• A escassez do espaço de endereços, o crescimento do estado de roteamento, o problema de dimensionamento de um solicitante individual e a atenção administrativa limitada eram restrições distintas. Elas surgiram em momentos diferentes e frequentemente orientavam para escolhas de alocação diferentes.
• Classes C múltiplas, a sub-rede, blocos contíguos e a delegação regional eram alternativas viáveis na época, mas cada uma impunha custos de roteamento, hardware, coordenação ou administrativos. Uma contrafactual justa não pode supor que o roteamento sem classes estava disponível ao longo dos anos 1980.

Um planejador de rede que esperava 300 hosts comuns encontrava uma descontinuidade precisa. Uma rede de classe C continha 256 valores possíveis em seu campo de endereço local de oito bits. De acordo com as restrições posteriormente clarificadas sobre os valores de host todos-zero e todos-um, ela fornecia 254 endereços de host comuns. A necessidade, portanto, excedia uma classe C em 46 endereços, e não em dois. O número dois descreve a diferença entre 256 valores numéricos e 254 endereços de host comuns; ele não descreve o déficit em relação a um plano de 300 hosts.

Duas redes de classe C podiam cobrir a necessidade imediata com 508 endereços de host comuns. No entanto, elas continuavam sendo duas redes por classes, podendo exigir duas entradas de roteamento visíveis externamente, dois registros e uma coordenação local adicional. A classe nativa seguinte, a classe B, fornecia 65.536 valores numéricos de endereços locais, ou seja, 65.534 endereços de host comuns. Isso representava aproximadamente 258,008 vezes a capacidade prática de hosts de uma classe C e mais de 218 vezes a necessidade declarada de 300 hosts.

O protocolo não continha uma classe intermediária. Ele não determinava se a conservação dos valores de endereços era mais importante que a conservação do estado de roteamento, se o hardware da organização podia sub-rede seguramente, se duas redes menores podiam ser coordenadas sem perturbação, ou qual crescimento deveria ser levado em conta. Essas questões precisavam ser resolvidas fora do padrão binário.

Esse é o ponto em que a granularidade técnica se tornou uma escassez administrativa. A escassez não começou apenas quando o pool restante se aproximava do esgotamento. Ela também aparecia sempre que a necessidade de um solicitante caía no grande fosso entre as unidades disponíveis e um administrador precisava determinar qual custo o sistema de alocação aceitaria.

A geometria criou uma fronteira de decisão

RFC 791, publicada em setembro de 1981, definia um endereço Internet como quatro octetos, ou 32 bits. Seus bits de alta ordem selecionavam um dos três formatos de endereços comuns e fixavam assim a divisão entre o número de rede e o endereço local.

A notação de barra está incluída apenas como uma tradução moderna das fronteiras fixas das classes. Não deve ser interpretada retrospectivamente como prova de que um administrador em 1981 podia atribuir um comprimento de prefixo arbitrário. Uma classe B não era um ponto em um menu contínuo. Seus bits iniciais indicavam às implementações por classes que tratassem os dois primeiros octetos como a parte da rede. Uma classe C fixava a fronteira após três octetos. O sistema não oferecia nativamente uma alocação roteável globalmente a meio caminho entre as duas.

A razão de capacidade numérica de uma classe para a seguinte era exatamente 256. Uma classe A continha \(2^{24}\) valores de endereços locais, uma classe B \(2^{16}\) e uma classe C \(2^8\). Após exclusão dos valores de host comuns todos-zero e todos-um, as razões práticas eram ligeiramente maiores:

• \(16.777.214 / 65.534 = 256,007782\) capacidades de classe B por classe A.
• \(65.534 / 254 = 258,007874\) capacidades de classe C por classe B.

As exclusões devem ser datadas. A RFC 791 estabeleceu a geometria das classes, mas não publicou uma tabela moderna de hosts utilizáveis. ARFC 950, publicada em 1985, explicava os significados especiais dos campos zero e todos-um no contexto da sub-rede e das difusões. ARFC 1122estipulava em 1989 que os campos host, rede e sub-rede não podiam assumir os valores todos-zero ou todos-um, exceto em casos especiais definidos.

Para comparar as alocações, os valores numéricos totais são a medida menos dependente de hipóteses: \(2^{24}\), \(2^{16}\) ou \(2^8\) por rede. Para reconstituir o problema de capacidade de hosts comuns de um solicitante de acordo com as regras posteriores, os números familiares menos dois são apropriados. Misturar essas duas medidas produz afirmações enganosas, como demonstra o exemplo dos 300 hosts.

Os padrões de bits de alta ordem também dividiam todo o espaço de 32 bits de forma desigual. Os endereços começando com0ocupavam metade de todas as cadeias binárias. O padrão10ocupava um quarto. O padrão110ocupava um oitavo. Os outros padrões de alta ordem eram reservados ou desenvolvidos para outros fins, incluindo multicast e experimentação. Assim, um pequeno número de números de rede de classe A controlava uma enorme parte do espaço de endereçamento numérico, enquanto o estoque muito maior de números de rede de classe C ocupava uma fração menor.

Essa distinção entre as unidades de números de rede e a capacidade representada é fundamental. Um registro podia conter milhares de entradas de classe C e apenas algumas dezenas de entradas de classe A, fazendo parecer que a classe C dominava em termos de carga de trabalho. O mesmo registro, medido em valores de endereços numéricos, podia estar massivamente concentrado em classe A. Nenhum dos dois denominadores é intrinsecamente errado. Eles respondem a perguntas diferentes.

A contagem de números de rede aproxima o número de unidades por classes que precisavam ser registradas e, quando visíveis externamente, roteadas. A capacidade representada mede quantos valores de endereços estavam dentro das alocações listadas. Nenhum dos dois é uma contagem de solicitantes. Nenhum mede hosts ativos, utilização, visibilidade de roteamento, propriedade organizacional ou valor econômico.

A arquitetura por classes produzia, portanto, duas formas de aspereza ao mesmo tempo. Ela oferecia poucas capacidades intermediárias aos solicitantes, e tornava a distribuição aparente fortemente dependente da unidade de análise do observador. O julgamento administrativo intervinha na primeira fronteira. O julgamento histórico pode se enganar na segunda.

O roteamento tornava a maior unidade operacionalmente atraente

A lacuna entre as classes B e C teria sido menos consequente se os roteadores pudessem agregar redes adjacentes arbitrárias sem modificar sua interpretação. Durante grande parte do período, eles não podiam.

A arquitetura original tratava a Internet como uma hierarquia de redes por classes. Uma gateway podia rotear pela parte de rede enquanto deixava o destinatário interpretar o campo de endereço local. Esse arranjo era econômico quando um número de rede correspondia razoavelmente bem a uma rede física ou a uma organização. Tornou-se mais difícil de manter à medida que universidades, empresas e redes públicas acumulavam edifícios, LANs, conexões ponto a ponto e gateways internas.

A RFC 950 descrevia três grandes opções para uma organização com várias LANs. Ela podia obter um número de rede Internet distinto para cada cabo. Podia fazer várias LANs parecerem uma única rede transparente. Ou podia dividir uma rede atribuída única em sub-redes.

A primeira opção preservava implementações de hosts simples, mas exportava a complexidade local para o sistema de roteamento global. A RFC 950 alertava que a propagação de cada rede local em escala global causaria uma explosão no tamanho das tabelas de roteamento, inclusive nas gateways com pouco espaço para informações de roteamento. A ponte transparente evitava números de rede Internet adicionais, mas trazia suas próprias limitações de escalabilidade e domínios de falha.

A sub-rede permitia que uma rede por classes externa contivesse várias redes internas, economizando entradas de roteamento global ao custo de implementações locais mais capazes.

A aritmética de sub-redes ilustra por que a classe B se tornou atraente para um campus em crescimento. Se seis bits de seu campo local de 16 bits fossem usados para sub-redes, a geometria bruta produzia 64 padrões de sub-rede e 1.024 padrões de host em cada sub-rede. De acordo com a convenção da época, que excluía os padrões de sub-rede todos-zero e todos-um, restavam 62 sub-redes comuns. Aplicando as exclusões habituais de hosts, restavam 1.022 valores de host por sub-rede. O produto era: \[62 \times 1.022 = 63.364\] Essa organização podia operar dezenas de redes internas atrás de um único número de classe B externo.

O arranjo usava muito mais valores de endereços do que um pequeno campus precisava inicialmente, mas economizava números de rede visíveis externamente e deixava espaço para crescimento interno.

A sub-rede não era isenta de custos. Os hosts e as gateways precisavam entender as máscaras. As alocações existentes no campo local podiam entrar em conflito com uma nova fronteira de sub-rede. O software precisava decidir se um destino era local ou exigia uma gateway usando mais do que a fronteira de classe fixa.

O guia operacional de 1989, aRFC 1118, descrevia diretamente o problema de compatibilidade. Muitos softwares disponíveis, especialmente 4.2BSD, não conseguiam lidar com endereços sub-rede sem software adicional, enquanto 4.3BSD suportava sub-rede nativamente. Outros sistemas variavam. Alguns podiam funcionar como folhas, mas não como gateways dentro de uma parte sub-rede da rede.

A RFC 1118 também dava ao custo de roteamento uma escala concreta. Ela indicava que alguns nós importantes só conseguiam armazenar e trocar informações para cerca de 700 redes. Aconselhava um campus a não anunciar mais de dois números de rede distintos. Dizia-se a um site que esperasse ultrapassar esse limite que considerasse a sub-rede.

O dilema do alocador não era, portanto, simplesmente "bloco grande contra bloco pequeno". Era uma escolha entre recursos consumidos em lugares diferentes:

• Uma classe B consumia uma grande parte do pool de endereços finito, mas podia economizar entradas de roteamento externo.
• Várias classes C economizavam os valores de endereços numéricos, mas podiam adicionar rotas e trabalho de coordenação local.
• A sub-rede economizava estado externo, mas exigia equipamento compatível e competência operacional.
• Adiar a decisão não economizava nem o esforço futuro de renumeração nem a atenção administrativa se o solicitante ultrapassasse rapidamente a alocação inicial.

O crescimento do estado de roteamento tornava o compromisso cada vez mais urgente. ARFC 1338reproduzia uma série da Merit mostrando 173 rotas anunciadas em julho de 1988, 603 em julho de 1989 e 4.775 em fevereiro de 1992. A comparação completa de julho de 1988 a fevereiro de 1992 era: \[4.775 / 173 = 27,601\] Isso era um aumento de 27,601 vezes em 43 meses. A comparação mais curta de julho de 1989 a fevereiro de 1992 era: \[4.775 / 603 = 7,919\] Isso era um aumento de 7,919 vezes em 31 meses. Essas são comparações diferentes e não devem ser combinadas.

A RFC 1338 argumentava que alocar de quatro a dezesseis classes C em vez de uma classe B podia retardar o esgotamento das classes B, mas piorar o crescimento das tabelas de roteamento, a menos que os protocolos de roteamento interdomínio pudessem representar agregados arbitrários rede-e-máscara. O remédio proposto dependia, portanto, de mais do que uma simples nova regra de registro. Os roteadores e os protocolos precisavam transportar informações que não correspondiam às antigas fronteiras de classes.

O solicitante de 300 hosts parece agora menos um exercício de aritmética trivial. Duas classes C ofereciam capacidade imediata suficiente, mas podiam exigir duas rotas. Uma classe B reduzia a representação externa a uma rede enquanto reservava 65.536 valores numéricos. A arquitetura criava a descontinuidade. O roteamento e o equipamento determinavam os custos relativos. O sistema administrativo precisava selecionar uma opção imperfeita.

A interface de decisão precoce permanece incompleta

A RFC 791 explicava o que significava uma classe. Ela não especificava quem deveria receber uma. Essa decisão transitou por um conjunto cambiante de instituições e procedimentos.

Em setembro de 1981, aRFC 790publicava os números de rede atribuídos e direcionava as solicitações de alocação para Jon Postel no Information Sciences Institute da University of Southern California. O registro mostrava os números atribuídos, reservados e não atribuídos, mas não publicava um teste geral completo para escolher entre as classes A, B e C.

Em janeiro de 1983, aRFC 820documentava um ambiente político mais elaborado. Ela rotulava as alocações como pesquisa e desenvolvimento, defesa ou comercial. Seu apêndice resumia as recomendações acordadas entre o escritório do programa Defense Data Network e a DARPA em setembro de 1982. Para a comunidade de pesquisa, as recomendações vinculavam a concessão de identificadores de rede à prova de que o solicitante estava adquirindo software de gateway padrão ou implementando uma gateway atendendo aos requisitos do protocolo de gateway externo (EGP).

Esse critério dizia respeito à elegibilidade e à preparação operacional. Ele não fornecia uma regra de dimensionamento completa. Podia distinguir um solicitante pronto para participar do ambiente de rede relevante de outro sem capacidade de gateway adequada, mas não dizia a um administrador se uma organização qualificada planejando 500 hosts deveria receber duas classes C ou uma classe B.

A RFC 820 também registrava uma lacuna de implementação entre a divisão prevista das responsabilidades e o funcionamento real. A divisão proposta não havia sido plenamente implementada, e Postel continuava sendo o coordenador das alocações de números. As descrições formais de papéis e a gestão diária ainda estavam convergindo.

O arranjo institucional mudou ao longo da década. OGuia dos arquivos SRI ARC/NIC do Computer History Museumdata a transferência da administração dos números atribuídos e da alocação global de endereços IP da USC-ISI para o contrato SRI NIC em 1987. O instrumento de pesquisa identifica correspondência e material de nomeação e endereçamento que podem conter registros de solicitações, mas não revela por si só o raciocínio por trás de uma decisão de classe individual.

A RFC 1118 fornecia uma descrição pública do procedimento destinado aos solicitantes em 1989. Uma rede conectada prospectiva deveria enviar uma mensagem para[email protected], solicitar o modelo de endereço conectado, preenchê-lo e devolvê-lo. O endereço atribuído era então devolvido por e-mail ou correio postal. O guia acrescentava que restavam poucos números de classe A e que, na prática, a maioria dos solicitantes deveria escolher entre classe B e classe C.

Isso estabelece que havia um formulário, um canal de retorno e um resultado. Isso não reproduz os formulários preenchidos e não demonstra quais campos determinavam a classe selecionada em um caso específico. Uma descrição procedimental não é um conjunto de dados solicitação-decisão.

A confirmação sobrevivente enviada à Universidade de Bristol também é limitada. A universidade reproduz uma mensagem datada de 8 de março de 1991 atribuindo137.222.0.0, uma rede de classe B, aBRISTOL-NET. Ela identifica a classe, o número, o contato técnico e a data. Também aconselha o destinatário sobre o registro da tabela de hosts, endereçamento de broadcast e resolução de endereços.

A confirmação não contém a solicitação submetida por Bristol, as previsões de hosts, o plano de sub-rede, as alternativas consideradas, as perguntas feitas pelo hostmaster ou as razões para a escolha da classe B. Ela prova um resultado, não a regra de decisão do administrador. É uma resposta sem a solicitação e a deliberação correspondentes.

As evidências diretas reunidas aqui não reconstituem, portanto, um par completo de solicitação-resposta ou solicitação-decisão precoce. As afirmações sobre o que um administrador precoce realmente viu devem permanecer como hipóteses. Um administrador plausível poderia ter levado em conta os hosts esperados, a topologia, as gateways, o software e a conectividade porque essas questões eram operacionalmente relevantes e apareciam nas diretrizes públicas. O material sobrevivente não demonstra que todos esses elementos foram submetidos ou ponderados em uma decisão precoce particular.

A distinção é importante porque as tabelas de alocação completadas são evidências particularmente tentadoras. Elas mostram o que foi registrado após aprovação. Elas não mostram a classe solicitada, o tamanho inicialmente oferecido, as previsões do solicitante, uma recusa, uma redução, um atraso ou uma necessidade não submetida. Deduzir a interface de decisão a partir da tabela completada transformaria resultados em motivações.

Em agosto de 1990, aRFC 1174descrevia os papéis institucionais de forma mais formal. A função IANA na USC-ISI mantinha a autoridade central para alocar e atribuir os identificadores numéricos e a autoridade discricionária para delegar partes dessa responsabilidade. A responsabilidade pelos identificadores de rede e sistema autônomo havia sido confiada ao Internet Registry gerenciado pela SRI International no DDN-NIC. O documento recomendava manter as funções centrais IANA e Internet Registry enquanto delegava blocos a organizações aprovadas internacionalmente.

Esses papéis não devem ser confundidos. A função IANA, o Internet Registry, o serviço NIC e o Internet Activities Board ocupavam posições relacionadas, mas distintas. O IAB emitia recomendações. A função IANA detinha a autoridade de alocação e delegação. O Internet Registry reunia e mantinha os registros e processava as alocações de números. O solicitante geralmente encontrava o sistema por meio de um hostmaster e de um número retornado.

A RFC 1174 prova que a discrição e a delegação eram conceitos institucionais reconhecidos em 1990. Ela não prova como a discrição foi exercida em um caso particular de 1983 ou 1991.

Medir a distribuição sem inventar solicitantes

Uma medida reproduzível pode ser construída a partir de instantâneos publicados contemporâneos, desde que sua unidade de observação permaneça estreita.

A unidade usada aqui é uma unidade de número de rede por classes conforme contada pela fonte citada. Não é uma organização, um solicitante, um prefixo roteado, um host, um detentor atual, uma transferência ou uma transação econômica. Se uma fonte associa um intervalo contendo 1.024 redes de classe C a um único nome, a medida conta 1.024 unidades por classes. Ela não afirma que o intervalo representa 1.024 beneficiários.

Três instantâneos publicados fornecem pontos de comparação úteis:

1. Os totais de janeiro de 1983 da RFC 820 para os números de rede de classe A, B e C atribuídos.
2. ARFC 1166, publicada em julho de 1990, e seus totais para as redes alocadas para Internet e usos independentes.
3. ARFC 1466, publicada em maio de 1993, e sua tabela intitulada "Network Number Statistics (May 1992)".

As faixas reservadas e não atribuídas, os números de sistema autônomo, o espaço multicast e as classes experimentais são excluídos. Os valores numéricos representados são calculados multiplicando cada contagem fonte por \(2^{24}\), \(2^{16}\) ou \(2^8\). O cálculo não subtrai as reservas de hosts, sub-redes ou broadcast porque os destinatários podiam estruturar seus campos locais de forma diferente e porque o objetivo é medir a capacidade numérica englobada por cada alocação por classes.

Para janeiro de 1983: \[(31 \times 16.777.216) + (24 \times 65.536) + (1.042 \times 256) = 521.933.312\]

Para julho de 1990: \[(34 \times 16.777.216) + (2.533 \times 65.536) + (16.214 \times 256) = 740.578.816\]

Para as estatísticas de maio de 1992: \[(49 \times 16.777.216) + (7.354 \times 65.536) + (44.014 \times 256) = 1.315.302.912\]

As redes de classe C dominavam a contagem de unidades de números de rede nos três instantâneos selecionados. Elas não dominavam a capacidade representada. Em janeiro de 1983, 31 alocações de classe A englobavam 99,648% dos valores de endereços numéricos nos totais publicados. As 1.042 unidades de classe C englobavam 0,051%.

A primeira linha contém uma concentração importante. A RFC 820 associava a faixa de192.1.xxxa192.4.xxxa "BBN local networks". Cada valor completo do segundo octeto cobria 256 números de rede de classe C. Quatro desses valores cobriam, portanto: \[4 \times 256 = 1.024\] Essas 1.024 unidades representavam: \[1.024 / 1.042 = 98,272553%\] da contagem de classe C no total de janeiro de 1983. Sua capacidade numérica combinada era: \[1.024 \times 256 = 262.144\] Isso equivalia a quatro redes de classe B em capacidade numérica bruta: \[4 \times 65.536 = 262.144\]

A faixa mostra por que as contagens de unidades de rede não podem ser lidas como contagens de beneficiários. Ela também mostra que a classe selecionada não era uma função mecânica da capacidade numérica agregada. Uma organização proeminente podia aparecer como uma grande coleção de pequenas unidades por classes em vez de um único bloco grosseiro.

A tabela publicada não diz por quê. Ela não mostra se as redes BBN eram roteadas separadamente, usadas para testes, reservadas para diferentes ambientes locais ou organizadas segundo outro plano técnico. Substituir por quatro classes B em uma contrafactual preserva a capacidade bruta, mas não necessariamente a topologia, a experimentação, o comportamento de roteamento ou a estrutura administrativa pretendida. A faixa é, portanto, uma evidência contra uma leitura simplista de uma organização/uma classe, não uma prova do raciocínio do administrador original.

A RFC 820 também contém irregularidades de publicação aparentes. Várias linhas de classe C de defesa repetem um valor numérico enquanto os totais contam unidades distintas. Números temporários, redes renomeadas e entradas de transição aparecem em outros lugares. Os totais próprios da fonte são, portanto, mais seguros para uma medida agregada do que uma contagem ingênua das linhas visíveis. Eles permanecem dependentes das definições da fonte.

O instantâneo de 1990 introduz um denominador diferente. A RFC 1166 reportava separadamente 4.210 redes atribuídas para ARPA-Internet e DDN-Internet, e 18.781 alocadas para Internet e usos independentes. O subconjunto conectado incluía 29 classes A, 1.209 classes B e 2.972 classes C. O total de alocações mais amplo continha 34 classes A, 2.533 classes B e 16.214 classes C.

O total mais amplo é apropriado para medir a capacidade por classes única em nível mundial colocada em uso atribuído ou alocado, incluindo redes independentes. O subconjunto conectado está mais próximo de uma contagem das redes nos ambientes Internet especificados. Nenhum dos dois totais é uma contagem de solicitantes. Nenhum revela quantas solicitações foram recusadas ou revisadas.

As fontes de 1992 advertem contra forçar os instantâneos em uma série contínua falsamente precisa. A RFC 1338 reportava que uma análise do arquivonetwork-contacts.txtdo DDN-NIC encontrou 46 classes A alocadas e 5.467 classes B alocadas em 25 de fevereiro de 1992. A RFC 1466 reproduziu posteriormente os totais de maio de 1992 de 49 e 7.354. Os documentos também usavam denominadores de pool de classes B diferentes: 16.256 na RFC 1338 e 16.383 na RFC 1466.

Seria imprudente interpretar toda a diferença como uma onda de alocações em três meses. Os arquivos, os filtros, o processamento das faixas reservadas ou os significados de "alocado" podem ter diferido. Sem os arquivos subjacentes datados e suas regras de transformação, a lacuna não pode ser resolvida a partir dos dois totais sozinhos. Os autores contemporâneos percebiam claramente um crescimento rápido, mas essa percepção não torna medidas diferentes intercambiáveis.

Os nomes dos beneficiários não corrigem o denominador ausente

Atribuir uma geografia é mais difícil do que multiplicar as contagens de classes. Os primeiros registros não forneciam um campo de país padrão ao lado de cada rede. Alguns nomes identificavam explicitamente um local ou instituição. Outros descreviam um projeto, um sistema experimental, um contratante ou uma rede transnacional. Um endereço de contato podia identificar onde a administração ocorria sem identificar cada país em que a rede operava.

As entradas de classe A da RFC 1166 incluíam casos claramente não americanos, entre eles RSRE no Reino Unido, CAN-INET no Canadá e JAPAN-A com um contato na Universidade de Tóquio. Os registros anteriores incluíam University College London e redes transatlânticas por pacote ou satélite. Isso é suficiente para rejeitar a afirmação de que as alocações de grande classe eram exclusivamente americanas. Isso não é suficiente para produzir uma porcentagem confiável por país.

Uma rede satélite transatlântica resiste à atribuição a um único país. Uma empresa pode operar em várias jurisdições. Um nome de projeto pode sobreviver ao seu local institucional original. Os registros posteriores do registro podem refletir fusões, transferências, reorganizações ou contatos modificados. A geografia atual não pode ser projetada para trás como geografia do beneficiário original sem uma cadeia documentada.

Os nomes também mudam a unidade de observação. Várias entradas podem pertencer a uma única organização; uma entrada pode suportar várias organizações ou locais de operação. A faixa de classe C da BBN é o exemplo mais claro de muitas unidades de números de rede sob um mesmo nome. O uso posterior pela Merit da rede 35 através de vários sistemas autônomos ilustra o problema inverso: uma rede por classes podia participar de um arranjo de roteamento distribuído.

A ausência de solicitação malsucedida é mais grave. Os registros publicados mostram principalmente alocações realizadas. Eles não divulgam a população completa de solicitantes. As observações ausentes podem incluir:

• solicitações devolvidas para informações complementares;
• solicitações concedidas em uma classe menor do que a inicialmente solicitada;
• solicitações atrasadas ou abandonadas;
• organizações direcionadas para um provedor ou outro registro;
• redes que usavam numeração privada ou não única;
• organizações que não conheciam o procedimento relevante;
• solicitantes dissuadidos pelas exigências de gateway, conectividade ou equipamento;
• beneficiários retidos cujos formulários originais não subsistem mais.

Sem esse denominador, os instantâneos não podem medir taxas de aprovação, atrasos, acesso desigual ou vantagem de precursor ao nível do solicitante. Eles não podem mostrar se solicitantes tecnicamente similares receberam classes diferentes. Eles não podem estabelecer que a capacidade de engenharia de uma organização tornava o sucesso mais provável.

Os dados podem estabelecer a aspereza, a concentração e a distribuição cambiante das unidades por classes. Eles podem identificar um mecanismo pelo qual alocações precoces duradouras poderiam preservar opções posteriores. Eles não podem converter esse mecanismo em um efeito social medido sem solicitações e resultados pareados.

Esse limite muda a linguagem da conclusão. "Os primeiros beneficiários tinham melhor acesso" exigiria evidências sobre solicitantes comparáveis. "Os administradores favoreciam os titulares capazes" exigiria evidências sobre as decisões e as alternativas. A afirmação defensável é condicional: se uma organização recebeu e implantou uma grande alocação antes que critérios mais estritos fossem publicados, o custo da renumeração podia permitir-lhe manter um conjunto de opções que um solicitante posterior poderia não receber nas mesmas condições.

Isso é uma dependência de caminho plausível. Não é um dividendo de precursor quantificado.

Os critérios públicos surgiram à medida que a pressão se acumulava

A interface precoce incompleta não deve ser confundida com ausência de qualquer critério. O registro mostra algumas regras de elegibilidade precoces e diretrizes de alocação posteriores muito mais explícitas.

O critério de pesquisa da RFC 820 vinculava a alocação de números à prontidão da gateway. Também recomendava continuidade quando uma rede experimental se tornava operacional: se a renumeração causasse dificuldades, a rede podia manter seu identificador enquanto sua categoria administrativa mudava. Isso era um reconhecimento explícito de que a implantação criava custos de mudança. Isso não mostra que os administradores antecipavam um valor de mercado futuro. Isso mostra que a continuidade já importava operacionalmente.

Em 1990, a RFC 1174 usava diretamente a linguagem da escassez. O crescimento rápido e a internacionalização tornavam uma delegação adicional oportuna, e os identificadores de classe A e B eram descritos como recursos cada vez mais escassos exigindo alocação cuidadosa. O documento juntava uma preocupação de capacidade a uma preocupação administrativa. Uma população mundial de solicitantes dependia de funções ainda centradas em instituições americanas, enquanto o número de redes e registros aumentava.

A resposta proposta era uma distribuição controlada, em vez de um abandono imediato da autoridade central. O Internet Registry permaneceria o registro principal e o registro padrão onde nenhuma autoridade delegada existisse. Organizações aprovadas podiam receber blocos e responsabilidade delegada. Cópias dos dados de registro agregados seriam distribuídas, enquanto as atualizações permaneceriam centralizadas.

ARFC 1366, publicada em outubro de 1992, transformou a orientação em regras mais específicas. Os registros regionais candidatos deveriam ser reconhecidos em suas áreas geográficas, estáveis, adequadamente recursos e comprometidos com diretrizes comuns da IANA e do Internet Registry. As funções centrais mantinham a responsabilidade pelo espaço de classe B, com os registros regionais auxiliando na avaliação.

Para a classe B, a RFC 1366 estabelecia dois critérios: um plano de sub-rede documentando mais de 32 sub-redes e mais de 4.096 hosts. Ela autorizava uma consideração caso a caso quando um bloco de classes C era tecnicamente inadequado. Para a classe C, ela propunha blocos contíguos em nível de bits, dimensionados conforme a necessidade e uma projeção de 24 meses.

Os critérios tornavam alguns fatores públicos enquanto deixavam uma margem de apreciação. "Mais de 32 sub-redes" dependia de uma topologia proposta. "Mais de 4.096 hosts" dependia do que contava como host e se o número descrevia a implantação atual ou um crescimento crível. A inadequação técnica exigia uma explicação, em vez de um cálculo automático.

A fonte canônica da épocaRIPE-048, publicada em 1º de agosto de 1992, mostra a interface europeia em desenvolvimento. Ela indicava que o RIPE NCC processava as solicitações das organizações europeias e que os solicitantes geralmente devolveriam o material fornecido por meio de um provedor de serviços IP ou do RIPE NCC. Ela vinculava a alocação às relações com provedores e à conectividade externa prospectiva.

RIPE-048 indicava que os números de classe A e B eram escassos e exigiam justificativa em termos de tamanho e estrutura de rede esperados. Uma solicitação de classe A exigia justificativa técnica detalhada e uma revisão global que podia levar vários meses. Ela aconselhava usar um conjunto razoável de classes C em vez de uma classe B quando a rede pudesse ser projetada dessa forma, notando explicitamente que isso invertia conselhos anteriores motivados pelas restrições de tabela de roteamento.

O documento fazia referência a uma folha de informações separada de uma página sobre a classe B, mas o texto inspecionado de RIPE-048 não reproduz essa folha. Seria, portanto, inadequado atribuir uma lista detalhada de campos de projeção de hosts, sub-rede e uso ao próprio RIPE-048. O suporte direto é mais estreito: tamanho e estrutura esperados, contexto de provedor ou conectividade, adequação da classe C, justificativa detalhada para classe A e possibilidade de uma longa revisão global.

A RFC 1466, publicada em maio de 1993, fornece diretamente os campos detalhados. Um solicitante de classe B deveria documentar mais de 32 sub-redes e mais de 4.096 hosts. O plano de engenharia deveria explicar por que um bloco de classes C era irrazoável e incluir o número de hosts esperados nos próximos 24 meses e o número de hosts por sub-rede nesse período. Os planos deveriam permanecer confidenciais e ser usados para julgar se a solicitação era justificada. Um solicitante que falhasse no teste receberia um bloco de classe C, enquanto exceções permaneciam possíveis.

Para a classe C, a RFC 1466 estabelecia uma escala de alocação contígua baseada na projeção de 24 meses do assinante:

Esses limiares usavam as necessidades de endereços, e não a capacidade prática de 254 hosts usada no exemplo de abertura. Essa distinção reflete a escala de alocação própria do documento e não deve ser silenciosamente "corrigida" para uma convenção diferente.

A política autorizava um ajuste para a topologia. Uma organização com 600 hosts distribuídos igualmente por dez Ethernets podia receber dez classes C, uma por LAN, se sustentasse a derrogação por um plano de engenharia. Os registros também podiam solicitar uma explicação quando a ausência de sub-rede das redes de classe C consumisse espaço excessivo.

A interface de decisão do período tardio era, portanto, mais visível que a do início. Os solicitantes sabiam que os totais de hosts, os planos de sub-rede, um horizonte de 24 meses e a adequação da classe C importavam. Eles também sabiam que exceções e o julgamento do registro permaneciam. A mudança não era de discrição para ausência de discrição. Ia de critérios públicos escassos para uma discrição estruturada.

Os casos-limite impedem uma história moral

As medidas agregadas podem sustentar várias histórias simplistas se seus limites forem ignorados. Os casos nomeados são valiosos porque enfraquecem essas histórias sem pretender revelar motivos não documentados.

A faixa BBN questiona a proposição de que os titulares proeminentes recebiam invariavelmente uma classe grosseira. Em janeiro de 1983, "BBN local networks" representava 1.024 das 1.042 unidades de classe C no total da fonte. Quatro classes B teriam fornecido a mesma capacidade numérica bruta com quatro unidades por classes. No entanto, o registro exibia a classe fina em volume.

Isso não prova que os administradores preferiam uma alocação de granularidade fina para a BBN. A razão original está ausente. A faixa pode ter suportado testes, redes locais separadas, experimentação ou objetivos administrativos internos. Seus membros podem não ter figurado todos como rotas globais independentes. A conclusão defensável é simplesmente que a notoriedade institucional não correspondia mecanicamente a uma alocação de grande classe.

Bristol questiona outra afirmação. Uma universidade europeia recebeu uma classe B em 8 de março de 1991, depois que o crescimento do roteamento era evidente e antes que os critérios detalhados de 1992-1993 fossem publicados. A confirmação descarta uma proposição absoluta de que as classes patrimoniais de tamanho médio estavam fechadas para universidades não americanas.

Ela não estabelece um tratamento igual. A solicitação está ausente, e não há um grupo pareado de universidades não atendidas. O caso prova que tal resultado ocorreu, não com que frequência nem por quê.

A rede 35 da Merit fornece um caso-limite operacional. A RFC 1166 listava a rede 35 entre as alocações de classe A. ARFC 1482, publicada em julho de 1993, mostrava-a configurada no backbone NSFNET T3 de modo que anúncios de roteamento podiam ser esperados de até seis sistemas autônomos.

Essa configuração de 1993 não estabelece a justificativa da alocação original. Ela mostra que um único número de rede por classes podia posteriormente desempenhar um papel operacional de tipo agregação em um ambiente roteado substancial. Um teste de uso retrospectivo baseado apenas no número de hosts ativos omitiria essa função de roteamento.

Esses casos restringem, em vez de provar, a tese. As grandes alocações não eram necessariamente irracionais. As coleções de redes pequenas não estavam confinadas a solicitantes marginais. As universidades não americanas não estavam categoricamente excluídas da classe B. Um grande número de rede podia ter um papel de roteamento além do número de hosts visíveis em um dado momento.

A falsificação funciona aqui removendo as afirmações universais. Ela não fornece os registros de decisão ausentes. BBN, Bristol e Merit devem ser tratados como casos-limite contra explicações simplistas, e não como janelas para o raciocínio original do administrador.

Quatro pressões surgiram em relógios diferentes

A palavra escassez pode obscurecer mais do que explica a menos que o recurso restrito seja nomeado.

A escassez do espaço de endereçamento finito dizia respeito ao espaço de 32 bits limitado e, mais imediatamente, aos estoques limitados de números de rede de classe A e classe B. Uma classe A englobava \(2^{24}\) valores de endereços locais numéricos e consumia um dos cerca de 126 slots de números de rede comuns reconhecidos nas tabelas da época. A RFC 1466 sinalizava apenas cerca de 11 números de classe A como não atribuídos ou não reservados de acordo com suas definições de política e reservava indefinidamente a metade superior do espaço de classe A.

A escassez do estado de roteamento dizia respeito à memória, processamento, atualizações de protocolo e estabilidade operacional. Ela podia se tornar aguda enquanto grandes partes do espaço de endereçamento numérico permaneciam não atribuídas. Cada classe C visível separadamente podia adicionar um destino à tabela de um roteador. O aviso da RFC 1118 sobre nós limitados a cerca de 700 redes e a série de roteamento da RFC 1338 mostram por que uma classe B com sub-rede podia parecer operacionalmente menos custosa do que várias redes menores.

A necessidade ao nível do solicitante era ainda diferente. A organização de 300 hosts não percebia todo o pool IPv4 como abundante. Ela percebia uma classe disponível como pequena demais em 46 endereços de host comuns e a seguinte como muito maior do que o necessário. Duas classes C resolviam o problema de capacidade, mas introduziam custos possíveis de roteamento e coordenação. A escassez do solicitante era uma falta de unidade de alocação bem adaptada.

A atenção administrativa dizia respeito à capacidade de receber formulários, fazer perguntas, avaliar planos, reconciliar registros, coordenar delegações e devolver decisões. A RFC 1174 vinculava uma delegação adicional ao crescimento rápido e à internacionalização. A RFC 1466 indicava que a demanda havia aumentado significativamente em dois anos e que a alocação exigia uma abordagem mais sistemática. RIPE-048 alertava que a revisão global de uma solicitação de classe A podia levar vários meses.

Essas pressões não evoluíam juntas. As tabelas de roteamento podiam crescer rapidamente mesmo que milhões de números de rede de classe C permanecessem teoricamente disponíveis. Um pequeno solicitante podia encontrar uma fronteira de classe severa enquanto o esgotamento numérico total permanecia distante. Um registro central podia enfrentar uma carga de trabalho crescente mesmo que cada formulário individual fosse fácil. Uma política projetada para conservar os números de classe B podia deliberadamente impor mais custos de equipamento ou roteamento aos solicitantes.

A separação também impede atalhos causais. A existência de um espaço de 32 bits finito não ditava um regime administrativo particular. O projeto das classes determinava as unidades disponíveis. As restrições de roteamento modificavam seus custos operacionais relativos. As instituições administrativas decidiam como distribuir a autoridade e avaliar as exceções. Os solicitantes forneciam previsões incompletas e escolhiam quais solicitações fazer.

A escassez não era um evento único. Era um conjunto de restrições desencontradas.

As alternativas viáveis todas tinham custos

Uma contrafactual da época deveria perguntar o que poderia ter sido razoavelmente feito com os protocolos, equipamentos e instituições então disponíveis. Ela não deve supor que um administrador em 1981 podia resolver o problema escrevendo um prefixo arbitrário moderno em um registro.

Considere uma organização esperando 1.000 hosts comuns. Quatro classes C ofereciam: \[4 \times 254 = 1.016\] endereços de host comuns. Uma classe B oferecia 65.534. Em termos de conservação de endereços, quatro classes C eram significativamente melhores. Em um sistema de roteamento por classes, elas podiam exigir quatro entradas de rede visíveis externamente. O conselho da RFC 1118 de que um campus não deveria anunciar mais de duas redes distintas tornava esse custo importante em 1989.

A primeira alternativa viável era alocar várias classes C e aceitar os números de rede adicionais. Isso não exigia um novo formato de endereço. Conservava a capacidade numérica e podia ser adequado para equipamentos que não suportavam sub-rede. Seus custos incluíam registros, configuração adicionais e potencialmente rotas globais. O crescimento futuro podia desencadear outra solicitação ou renumeração.

A segunda alternativa era alocar uma classe B e exigir sub-rede interna. Isso conservava o estado de roteamento externo e dava à organização uma margem de crescimento considerável. Seus custos eram uma reserva muito maior de valores de endereços numéricos e uma dependência de hosts e gateways capazes de sub-rede. Em uma época de mistura de 4.2BSD, 4.3BSD e outras implementações, a compatibilidade era uma preocupação operacional, em vez de uma ficção administrativa.

Uma terceira opção era alocar classes C contíguas em preparação para uma agregação posterior. A contiguidade ajudava a preservar a possibilidade de representar várias redes como um único prefixo uma vez que os protocolos de roteamento e os roteadores suportassem informações rede-e-máscara arbitrárias. Antes de tal suporte, o sistema por classes ainda interpretava os componentes como redes de classe C individuais. A contiguidade sozinha não fazia as entradas de roteamento desaparecerem.

A RFC 1338 tornava essa dependência explícita. Seu plano de alocação proposto podia dar blocos de classe C de tamanho apropriado a organizações médias, mas a vantagem de roteamento exigia que os protocolos interdomínio representassem destinos rede-mais-máscara arbitrários. As organizações multihomed ainda podiam exigir anúncios mais específicos. A implantação exigia mudanças de software, coordenação operacional e acordo entre o NIC, a IANA e os provedores de serviços.

Uma sub-rede mais precoce era outra resposta viável, mas ela resolvia a topologia interna dentro de uma classe alocada. Ela não reduzia o tamanho da classe concedida. Uma classe B com sub-rede ainda colocava 65.536 valores numéricos sob uma única alocação. Dividir uma classe A entre organizações não relacionadas teria exigido uma camada de roteamento e administração compartilhada ou um suporte externo sem classes que a arquitetura de dois níveis original não fornecia.

A ponte transparente podia fazer várias LANs parecerem uma única rede, mas deslocava a complexidade para um domínio de camada de enlace mais amplo. Ela não eliminava os custos de falha, desempenho ou coordenação. Não era um substituto universal para sub-redes roteadas.

A delegação regional ou baseada em provedores podia distribuir a atenção administrativa sem mudar o formato de endereço. Blocos de números de classe C podiam ser delegados a organizações mais próximas dos solicitantes. Isso podia encurtar os caminhos de comunicação, melhorar o serviço em língua local e afastar a revisão de rotina do registro central.

A delegação também criava custos. Os organismos centrais e regionais precisavam de registros consistentes, critérios comuns e procedimentos de atualização confiáveis. Alguém precisava decidir qual instituição regional possuía legitimidade, recursos e neutralidade. As RFCs 1366 e 1466 dedicavam atenção substancial a essas qualificações porque a delegação transferia uma autoridade consequente, em vez de um simples trabalho postal.

Outra possibilidade era exigir renumeração ou recuperação mais frequente. Isso podia recuperar capacidade não utilizada, mas imporia custos aos hosts, gateways, controles de acesso, documentação, redes correspondentes e pessoal operacional. A recomendação de continuidade da RFC 820 mostra que a dificuldade da renumeração já era reconhecida. Uma regra que ignorasse esses custos conservaria os valores de endereços exportando a perturbação para os operadores.

Cada alternativa, portanto, precificava a escassez de forma diferente:

• Classes C múltiplas economizavam valores de endereços, mas podiam consumir rotas e transações administrativas.
• Uma classe B com sub-rede economizava estado externo, mas consumia uma unidade de endereço grosseira e exigia equipamento compatível.
• Classes C contíguas preservavam opções de agregação futuras, mas não forneciam roteamento sem classes imediato.
• A delegação regional distribuía a revisão, mas exigia coordenação, legitimidade e consistência de registros.
• A renumeração recuperava capacidade ao custo da continuidade operacional.

O sistema observado não era o único sistema tecnicamente possível. Era uma resposta aos custos que não podiam ser todos minimizados simultaneamente.

O que mudou, o que persistiu e o que não pode ser deduzido

As evidências sustentam uma repartição dividida da causalidade.

O projeto por classes criou as descontinuidades. O endereço de 32 bits poderia ter sido dividido de outras formas, mas a arquitetura implantada oferecia fronteiras fixas A, B e C. Para uma necessidade logo acima de 254 hosts comuns, não existia uma classe nativa oferecendo um aumento modesto. Isso era uma propriedade do protocolo.

O roteamento e o hardware tornavam as descontinuidades economicamente e operacionalmente significativas. Várias classes C podiam economizar valores de endereços enquanto aumentavam as cargas de números de rede e roteamento. Uma classe B com sub-rede podia economizar estado externo enquanto exigia software adequado e consumia uma alocação muito maior. Essas eram restrições visíveis para os engenheiros contemporâneos.

A política administrativa determinava a resposta do sistema. Os primeiros documentos publicados continham critérios de elegibilidade e prontidão de gateway, mas não reconstituem uma interface completa de seleção de classe. Entre 1990 e 1993, o registro público discutia explicitamente a escassez, a delegação, os limiares de hosts e sub-redes, as projeções de 24 meses, os planos de engenharia e as exceções. O julgamento tornou-se mais estruturado sem desaparecer.

Os resultados ao nível dos solicitantes permanecem subdeterminados. Os instantâneos disponíveis carecem de solicitações completas, recusas, alternativas, registros de uso e explicações de decisão. Eles não podem estabelecer que os solicitantes tecnicamente capazes gozavam de acesso geralmente superior ou que os administradores favoreciam sistematicamente os titulares. Eles também não podem estabelecer que as grandes alocações precoces eram justificadas em cada caso.

Os instantâneos mostram, no entanto, um mecanismo plausível de dependência de caminho. Uma vez que um beneficiário implantava uma alocação, a renumeração impunha custos. A RFC 820 reconhecia explicitamente a dificuldade como uma razão para manter um número quando uma rede experimental se tornava operacional. Uma grande alocação precoce podia, portanto, permanecer em vigor após os critérios para novas alocações comparáveis se tornarem mais restritivos.

A vantagem deve ser descrita como uma opção, não como um dividendo medido. O beneficiário podia expandir internamente, continuar apresentando um destino por classes, renumerar com menos frequência ou manter uma capacidade cuja aquisição posterior se tornou difícil. Se um beneficiário particular usou essas opções, as mereceu ou antecipou sua importância posterior é uma questão empírica distinta.

Evidências modernas confirmam a persistência sem resolver os motivos precoces. Um estudo de 2017 sobre transferências de IPv4 reportadas descobriu que o espaço legado representava 63,82% do espaço de endereçamento em sua amostra de transferências reportadas. A mesma pesquisa mostrou por que os registros posteriores devem ser interpretados com cautela: as mudanças de roteamento podem refletir mudanças de provedor, realocações, reestruturações organizacionais ou gestão de endereços complexa, em vez de uma venda.

Esse resultado só é relevante como uma verificação estreita. Ele mostra que as alocações da era pré-registro persistiram tempo suficiente para participar materialmente da redistribuição posterior. Ele não mostra por que uma classe foi selecionada em 1983, se o solicitante original forneceu uma previsão exata, se a alocação era justa ou o que um administrador precoce pretendia fazer.

O valor monetário atual está ainda mais distante da decisão precoce. Um preço atual aplicado a todos os endereços dentro de um bloco legado ignoraria o espaço não roteado, as restrições políticas, os custos de transação, a fragmentação, as dependências operacionais e a distinção entre registro e controle. Mais importante, isso substituiria uma escassez posterior pelo padrão contemporâneo.

A conclusão histórica é, portanto, limitada, mas pesada de consequências. O IPv4 por classes converteu a granularidade técnica em uma fronteira de decisão administrativa. Os limites de roteamento tornavam às vezes a maior unidade defensável. Os limites de equipamento tornavam às vezes a sub-rede custosa. Os primeiros solicitantes e administradores operavam com previsões que não podem ser reconstituídas hoje a partir dos registros completados. As políticas posteriores tornaram os critérios de equilíbrio mais explícitos e deslocaram o trabalho para instituições regionais e baseadas em provedores.

A escassez administrativa nasceu na lacuna entre 254 e 65.534, mas não porque a lacuna ditava uma resposta única. Ela nasceu porque cada resposta disponível impunha custos a uma parte ou a um sistema diferente, e alguém precisava decidir qual custo aceitar.

Fontes

• RFC 790,Números atribuídos
• RFC 791,Protocolo Internet
• RFC 820,Números atribuídos
• RFC 950,Procedimento padrão de sub-rede Internet
• RFC 1118,O guia do mochileiro da Internet
• RFC 1122,Requisitos para hosts Internet — Camadas de comunicação
• RFC 1166,Números Internet
• RFC 1174,Política recomendada pelo IAB sobre a distribuição da alocação de identificadores Internet
• RFC 1338,Supernetting: uma estratégia de alocação e agregação de endereços
• RFC 1366,Diretrizes para a gestão do espaço de endereçamento IP
• RFC 1466,Diretrizes para a gestão do espaço de endereçamento IP
• RFC 1482,Suporte da agregação na base de dados de roteamento baseada em políticas da NSFNET
• RIPE-048,Modelo de números de rede Internet RIPE
• Computer History Museum,Guia dos arquivos SRI ARC/NIC
• Universidade de Bristol,25 anos de Internet na Universidade de Bristol
• Sobre os mercados de transferência IPv4: análise das transferências reportadas e inferência das transferências na natureza