A Era do Endereçamento Classful e o Nascimento da Escassez Administrativa

Resumo

• Uma rede que exigia 300 endereços de host comuns excedia a capacidade prática de 254 endereços de uma rede Classe C em 46 endereços. 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 maior coordenação. A geometria classful, portanto, tornava a alocação uma escolha entre custos distintos, em vez de uma simples leitura da demanda de hosts.
• Três instantâneos contemporâneos mostram que as redes Classe C dominavam a contagem de unidades de número de rede atribuídas, enquanto as atribuições Classe A dominavam a capacidade de endereços representada. Em janeiro de 1983, 31 atribuições Classe A representavam 99,648 por cento dos valores numéricos de endereços abrangidos pelos totais publicados; 1.042 Classes C representavam 0,051 por cento.
• O material sobrevivente não fornece uma amostra pareada de requisições iniciais, recusas e decisões. Ele não pode estabelecer um efeito genérico de vantagem do pioneiro, acesso desigual dos solicitantes ou os critérios usados em uma decisão inicial particular de classe. Ele apoia uma conclusão mais restrita: atribuições duradouras feitas antes que os critérios posteriores se tornassem explícitos poderiam criar uma vantagem de opção plausível dependente da trajetória.
• A escassez de espaço de endereçamento, o crescimento do estado de roteamento, o problema de dimensionamento de um solicitante individual e a atenção administrativa limitada eram restrições separadas. Elas apareceram em momentos diferentes e frequentemente apontavam para escolhas de alocação diferentes.
• Múltiplas Classes C, sub-redes, blocos contíguos e delegação regional eram alternativas viáveis no período, mas cada uma impunha custos de roteamento, hardware, coordenação ou administrativos. Uma contrafactual justa não pode supor que o roteamento sem classes estivesse disponível durante toda a década de 1980.

Um planejador de rede que esperava 300 hosts comuns encontrava uma descontinuidade precisa. Uma rede Classe C continha 256 valores possíveis em seu campo de endereço local de oito bits. Sob as restrições posteriormente esclarecidas de valores de host todos-zero e todos-um, ela fornecia 254 endereços de host comuns. A necessidade era, portanto, 46 endereços além de uma Classe C, não 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 Classe C poderiam cobrir a necessidade imediata com 508 endereços de host comuns. No entanto, elas permaneciam sendo duas redes classful, potencialmente exigindo duas entradas de roteamento externas, dois registros e coordenação local adicional. A classe nativa seguinte, Classe B, fornecia 65.536 valores numéricos de endereço local, ou 65.534 endereços de host comuns. Isso era cerca de 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 decidia se a conservação de valores de endereço era mais importante do que a conservação do estado de roteamento, se o hardware da organização poderia criar sub-redes com segurança, se duas redes menores poderiam ser coordenadas sem interrupção, ou quanto crescimento deveria ser creditado. Essas questões tiveram que ser resolvidas fora do padrão de bits.

Este é o ponto em que a granularidade técnica se tornou escassez administrativa. A escassez não começou apenas quando o pool remanescente se aproximou da exaustão. Ela também aparecia sempre que a necessidade de um solicitante caía na ampla lacuna entre as unidades disponíveis e um administrador tinha que determinar qual custo o sistema de alocação aceitaria.

A geometria criou uma fronteira de decisão

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

A notação de barra é incluída apenas como uma tradução moderna dos limites fixos de classe. Ela não deve ser lida retroativamente como evidência de que um administrador em 1981 poderia atribuir um comprimento de prefixo arbitrário. Uma Classe B não era um ponto em um menu contínuo. Seus bits iniciais diziam às implementações classful que tratassem os dois primeiros octetos como a parte da rede. Uma Classe C fixava o limite após três octetos. O sistema não oferecia nativamente uma alocação roteável globalmente a meio caminho entre eles.

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ço local, uma Classe B (2^{16}) e uma Classe C (2^8). Após excluir os valores comuns de host 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 precisam ser datadas. A RFC 791 estabeleceu a geometria de classes, mas não publicou uma tabela moderna de hosts utilizáveis.RFC 950, emitida em 1985, explicou os significados especiais dos campos de zero e todos-um no contexto de sub-redes e broadcasts.RFC 1122afirmou, em 1989, que os campos de host, rede e sub-rede não podiam assumir valores todos-zero ou todos-um, exceto em casos especiais definidos.

Para comparar alocações, os valores numéricos totais são a medida menos dependente de suposições: (2^{24}), (2^{16}) ou (2^8) por rede. Para reconstruir o problema de capacidade de hosts comuns de um solicitante sob as regras esclarecidas posteriormente, as figuras familiares de subtração de dois são apropriadas. Misturar essas duas medidas produz alegações enganosas, como o exemplo dos 300 hosts demonstra.

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

Essa distinção entre unidades de número de rede e capacidade representada é fundamental. Um registro poderia conter milhares de entradas Classe C e apenas algumas dezenas de entradas Classe A, fazendo a Classe C parecer dominante como carga de trabalho. O mesmo registro, medido por valores numéricos de endereço, poderia estar esmagadoramente concentrado na Classe A. Nenhum dos denominadores está intrinsecamente errado. Eles respondem a perguntas diferentes.

A contagem de números de rede aproxima o número de unidades classful que tiveram que ser registradas e, quando externamente visíveis, roteadas. A capacidade representada mede quantos valores de endereço estavam dentro das atribuições listadas. Nenhuma dessas medidas é uma contagem de solicitantes. Nenhuma mede hosts ativos, utilização, visibilidade no roteamento, propriedade organizacional ou valor econômico.

A arquitetura classful, portanto, produzia duas formas de aspereza ao mesmo tempo. Ela fornecia muito poucas capacidades intermediárias para os solicitantes e fazia a distribuição aparente depender fortemente da unidade de análise do observador. O julgamento administrativo entrava na primeira fronteira. O julgamento histórico pode errar na segunda.

O roteamento tornou a unidade maior operacionalmente atraente

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

A arquitetura original tratava a Internet como uma hierarquia de redes classful. Um gateway podia rotear pela porção de rede, deixando ao destinatário a interpretação do 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. Ele se tornou mais difícil de sustentar à medida que universidades, empresas e redes públicas acumulavam edifícios, redes de área local, conexões ponto a ponto e gateways internos.

A RFC 950 descreveu três opções amplas para uma organização com múltiplas LANs. Ela poderia obter um número de rede da Internet separado para cada cabo. Poderia fazer várias LANs parecerem uma única rede transparente. Ou poderia dividir uma única rede atribuída em sub-redes.

A primeira opção preservava implementações de host simples, mas exportava a complexidade local para o sistema de roteamento global. A RFC 950 advertiu que propagar cada rede local globalmente causaria uma explosão no tamanho da tabela de roteamento, inclusive em gateways com pouco espaço para informações de roteamento. A ponte transparente evitava números de rede adicionais da Internet, mas trazia suas próprias limitações de dimensionamento e domínio de falha.

A criação de sub-redes permitia que uma rede classful externa contivesse várias redes internas, conservando entradas de roteamento globais ao custo de implementações locais mais capazes.

A aritmética das 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 dentro de cada sub-rede. Sob a convenção do período que excluía os padrões de sub-rede todos-zero e todos-um, restavam 62 sub-redes comuns. Aplicando as exclusões comuns de host, 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 por trás de um único número de Classe B externo. O arranjo usava muito mais valores de endereço do que um campus pequeno inicialmente exigia, mas economizava em números de rede externamente visíveis e deixava espaço para crescimento interno.

A criação de sub-redes não era gratuita. Hosts e gateways precisavam entender máscaras. Atribuições existentes dentro do campo local podiam conflitar com um limite de sub-rede recém-escolhido. O software tinha que decidir se um destino era local ou exigia um gateway usando mais do que o limite fixo de classe.

O guia operacional de 1989RFC 1118descreveu o problema de compatibilidade diretamente. Muito do software disponível, notavelmente o 4.2BSD, não podia lidar com endereços sub-redeados sem software adicional, enquanto o 4.3BSD suportava sub-redes conforme lançado. Outros sistemas variavam. Alguns podiam funcionar como folhas, mas não como gateways dentro de uma parte sub-redeada da rede.

A RFC 1118 também deu ao custo de roteamento uma escala concreta. Ela dizia que alguns nós importantes podiam armazenar e trocar informações para apenas cerca de 700 redes. Ela aconselhava um campus a não anunciar mais do que dois números de rede discretos. Um site que esperasse exceder esse limite era instruído a considerar a criação de sub-redes.

O dilema do alocador, portanto, não era simplesmente “bloco grande versus 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 conservar entradas de roteamento externas.
• Várias Classes C conservavam valores de endereço numéricos, mas podiam adicionar rotas e trabalho de coordenação local.
• A criação de sub-redes conservava o estado externo, mas exigia equipamento compatível e competência operacional.
• Adiar a decisão não conservava nem o futuro esforço de renumeramento nem a atenção administrativa se o solicitante logo superasse a atribuição inicial.

O crescimento do estado de roteamento tornou a troca cada vez mais urgente.RFC 1338reproduziu 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 ao longo de 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 ao longo de 31 meses. Estas são comparações diferentes e não devem ser combinadas.

A RFC 1338 argumentou que alocar de quatro a dezesseis Classes C em vez de uma Classe B poderia retardar o esgotamento da Classe B, mas piorar o crescimento da tabela de roteamento, a menos que os protocolos de roteamento interdomínio pudessem representar agregações arbitrárias de rede e máscara. O remédio proposto, portanto, dependia de mais do que uma nova regra de registro. Roteadores e protocolos tinham que transportar informações que não se encaixavam nos limites de classe antigos.

O solicitante com 300 hosts agora parece menos um exercício aritmético trivial. Duas Classes C ofereciam capacidade imediata suficiente, mas podiam exigir duas rotas. Uma Classe B reduzia a representação externa para uma única rede, reservando 65.536 valores numéricos. A arquitetura criou a descontinuidade. O roteamento e o equipamento determinavam os custos relativos. O sistema administrativo tinha que selecionar uma opção imperfeita.

A interface de decisão inicial permanece incompleta

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

Em setembro de 1981,RFC 790publicou números de rede atribuídos e direcionou os pedidos de atribuições a Jon Postel, no Information Sciences Institute da Universidade do Sul da Califórnia. O registro mostrava números atribuídos, reservados e não atribuídos, mas não publicava um teste geral completo para escolher entre Classe A, B e C.

Em janeiro de 1983,RFC 820documentou um ambiente de política mais elaborado. Ela rotulava as atribuições como pesquisa e desenvolvimento, defesa ou comercial. Seu apêndice resumia 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 à evidência de que o solicitante estava adquirindo software de gateway padrão ou implementando um gateway que atendesse aos requisitos do External Gateway Protocol.

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

A RFC 820 também registrou uma lacuna de implementação entre a divisão de responsabilidades pretendida e a operação real. A divisão proposta não havia sido totalmente implementada, e Postel permaneceu como coordenador das atribuições de números. As descrições formais de papéis e o tratamento diário ainda estavam convergindo.

O arranjo institucional mudou durante a década. OGuia para os Registros SRI ARC/NICdo Computer History Museum data a transferência da administração de Números Atribuídos e da alocação global de endereços IP do USC-ISI para o contrato SRI NIC em 1987. O auxílio à pesquisa identifica correspondências e material de nomeação e endereçamento que podem conter registros de solicitação, mas não revela por si só o raciocínio por trás de qualquer decisão de classe individual.

A RFC 1118 forneceu uma descrição pública do procedimento voltado para o solicitante em 1989. Uma futura rede conectada era instruída a enviar uma mensagem para[email protected], solicitar o modelo de endereço conectado, preenchê-lo e devolvê-lo. O endereço atribuído seria então enviado de volta por correio eletrônico ou postal. O guia acrescentava que poucos números de Classe A restavam e que, em termos práticos, a maioria dos solicitantes tinha que 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 nem demonstra quais campos determinavam a classe selecionada em qualquer caso específico. Uma descrição procedimental não é um conjunto de dados de solicitação-decisão.

A confirmação sobrevivente enviada à Universidade de Bristol é igualmente limitada. A universidade reproduz uma mensagem datada de 8 de março de 1991 atribuindo137.222.0.0, uma rede 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 de tabelas de host, endereçamento de broadcast e resolução de endereços.

A confirmação não contém a solicitação enviada por Bristol, a previsão de hosts, o plano de sub-redes, as alternativas consideradas, as perguntas feitas pelo hostmaster ou as razões para selecionar a 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, portanto, não reconstroem um par completo de solicitação-resposta ou solicitação-decisão inicial. Alegações sobre o que um administrador inicial realmente viu devem permanecer como hipóteses. Um administrador plausível poderia ter considerado hosts esperados, topologia, gateways, software e conectividade porque essas questões eram operacionalmente relevantes e apareciam nas orientações públicas. O material sobrevivente não demonstra que todas elas foram submetidas ou ponderadas em uma determinada decisão inicial.

A distinção importa porque as tabelas de alocação preenchidas são evidências especialmente tentadoras. Elas mostram o que foi registrado após a aprovação. Elas não mostram a classe solicitada, o tamanho oferecido primeiro, a previsão de um solicitante, uma recusa, uma redução, um atraso ou uma necessidade não submetida. Inferir a interface de decisão a partir da tabela preenchida transformaria resultados em motivos.

Em agosto de 1990,RFC 1174descreveu os papéis institucionais de forma mais formal. A função IANA no USC-ISI retinha a autoridade central para alocar e atribuir identificadores numéricos e a autoridade discricionária para delegar partes dessa responsabilidade. A responsabilidade pelos identificadores de rede e de sistema autônomo havia sido alojada no Internet Registry operado pelo SRI International no DDN-NIC. O documento recomendava reter as funções centrais da IANA e do Internet Registry enquanto se delegavam blocos a organizações aprovadas internacionalmente.

Esses papéis não devem ser colapsados. 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 coletava e mantinha registros e processava as atribuições de números. O solicitante geralmente encontrava o sistema através de um hostmaster e um número devolvido.

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

Medindo a distribuição sem inventar solicitantes

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

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

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

1. Os totais de janeiro de 1983 da RFC 820 para números de rede Classe A, B e C atribuídos.
2. RFC 1166, publicada em julho de 1990, e seus totais para redes alocadas para usos da Internet e independentes.
3. RFC 1466, publicada em maio de 1993, e sua tabela rotulada “Estatísticas de Números de Rede (maio de 1992).”

Intervalos reservados e não atribuídos, números de sistemas autônomos, espaço multicast e classes experimentais são excluídos. Os valores numéricos representados são calculados multiplicando-se cada contagem da fonte por (2^{24}), (2^{16}) ou (2^8). O cálculo não subtrai as reservas de host, sub-rede ou broadcast, porque os destinatários podiam estruturar seus campos locais de forma diferente e porque o propósito é medir a capacidade numérica abrangida por cada atribuição classful.

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 Classe C dominavam a contagem de unidades de número de rede em todos os três instantâneos selecionados. Elas não dominavam a capacidade representada. Em janeiro de 1983, 31 atribuições Classe A abrangiam 99,648 por cento dos valores numéricos de endereço nos totais publicados. As 1.042 unidades Classe C abrangiam 0,051 por cento.

A primeira linha contém uma concentração importante. A RFC 820 associava o intervalo de192.1.xxxa192.4.xxxcom “redes locais BBN.” Cada valor completo de segundo octeto cobria 256 números de rede Classe C. Quatro desses valores, portanto, cobriam:

[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 era igual a quatro redes Classe B em capacidade numérica bruta:

[4 \times 65.536 = 262.144]

O intervalo mostra por que as contagens de unidades de rede não podem ser lidas como contagens de beneficiários. Também mostra que a classe selecionada não era uma função mecânica da capacidade numérica agregada. Uma organização proeminente poderia aparecer como uma grande coleção de pequenas unidades classful, em vez de como 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 sob algum outro plano técnico. Substituir 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. O intervalo é, portanto, evidência contra uma leitura simplista de uma organização/uma classe, não evidência do raciocínio do administrador original.

A RFC 820 também contém aparentes irregularidades de publicação. 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 próprios totais da fonte são, consequentemente, mais seguros para medição agregada do que uma contagem ingênua de linhas visíveis. Eles permanecem dependentes das definições da fonte.

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

O total mais amplo é apropriado para medir a capacidade classful globalmente única colocada em uso atribuído ou alocado, incluindo redes independentes. O subconjunto conectado está mais próximo de uma contagem de redes dentro dos ambientes da Internet especificados. Nenhum dos totais é uma contagem de solicitantes. Nenhum revela quantas solicitações foram negadas ou revisadas.

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

Seria inseguro interpretar toda a diferença como um surto de alocação de três meses. Os arquivos, filtros, tratamento de intervalos reservados ou significados de “alocado” podem ter diferido. Sem os arquivos subjacentes datados e suas regras de transformação, a discrepância não pode ser resolvida apenas a partir dos dois totais. Os autores contemporâneos claramente perceberam um rápido crescimento, mas essa percepção não torna medições diferentes intercambiáveis.

Os nomes dos destinatários não consertam o denominador ausente

Atribuir geografia é mais difícil do que multiplicar contagens de classe. Os primeiros registros não forneciam um campo de país padrão ao lado de cada rede. Alguns nomes identificavam explicitamente um lugar ou instituição. Outros descreviam um projeto, sistema experimental, contratante ou rede transnacional. Um endereço de contato podia identificar onde a administração ocorria sem identificar todos os países nos quais 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 da Universidade de Tóquio. Registros anteriores incluíam o University College London e redes de satélite ou pacote transatlânticas. Isso é suficiente para rejeitar a alegação de que as atribuições de classes grandes eram exclusivamente americanas. Não é suficiente para produzir uma porcentagem confiável por país.

Uma rede de satélite transatlântica resiste à atribuição a um único país. Uma corporação pode operar em várias jurisdições. Um nome de projeto pode sobreviver à sua localização institucional original. Registros posteriores do registro podem refletir fusões, transferências, reorganizações ou contatos alterados. A geografia presente não pode ser projetada retroativamente como a geografia do destinatário original sem uma cadeia documentada.

Os nomes também mudam a unidade de observação. Várias entradas podem pertencer a uma organização; uma entrada pode sustentar várias organizações ou locais operacionais. O intervalo de Classe C da BBN é o exemplo mais claro de muitas unidades de número de rede sob um nome. O uso posterior da rede 35 pela Merit em vários sistemas autônomos ilustra o problema inverso: uma rede classful podia participar de um arranjo de roteamento distribuído.

A ausência de demanda malsucedida é mais séria. Os registros publicados mostram predominantemente atribuições concluídas. Eles não revelam a população total de solicitantes. As observações ausentes podem incluir:

• solicitações devolvidas para informações adicionais;
• solicitações concedidas em uma classe menor do que a originalmente procurada;
• aplicações atrasadas ou abandonadas;
• organizações direcionadas a um provedor ou outro registro;
• redes que usaram numeração privada ou não única;
• organizações que não conheciam o procedimento relevante;
• solicitantes dissuadidos pelos requisitos de gateway, conectividade ou equipamento;
• destinatários bem-sucedidos cujos formulários originais não sobreviveram.

Sem esse denominador, os instantâneos não podem medir taxas de aprovação, atrasos, acesso desigual ou vantagem do pioneiro no nível do solicitante. Eles não podem mostrar se solicitantes tecnicamente semelhantes 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 aspereza, concentração e a distribuição mutável de unidades classful. Eles podem identificar um mecanismo pelo qual atribuições iniciais duradouras poderiam preservar opções posteriores. Eles não podem converter esse mecanismo em um efeito social medido sem solicitações e resultados pareados.

Este limite muda a linguagem da conclusão. “Os primeiros destinatários tinham melhor acesso” exigiria evidência sobre solicitantes comparáveis. “Os administradores favoreciam titulares capazes” exigiria evidência sobre decisões e alternativas. A alegação defensável é condicional: se uma organização recebeu e implantou uma grande atribuição antes que critérios publicados mais rigorosos existissem, o custo de renumeramento poderia permitir que ela retivesse um conjunto de opções que um solicitante posterior poderia não receber nos mesmos termos.

Isso é dependência de trajetória plausível. Não é um dividendo de pioneiro quantificado.

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

A interface inicial incompleta não deve ser confundida com uma ausência de todos os critérios. O registro mostra algumas regras iniciais de elegibilidade e orientações de alocação posteriores muito mais explícitas.

O critério de pesquisa da RFC 820 vinculava a atribuição de números à prontidão do gateway. Também recomendava continuidade quando uma rede experimental se tornasse operacional: se o renumeramento causasse dificuldades, a rede poderia manter seu identificador enquanto sua categoria administrativa fosse alterada. Isso era um reconhecimento explícito de que a implantação criava custos de troca. Isso não mostra que os administradores anteciparam um valor de mercado futuro. Mostra que a continuidade já importava operacionalmente.

Em 1990, a RFC 1174 usava diretamente a linguagem da escassez. O rápido crescimento e a internacionalização tornavam oportuna uma delegação adicional, e os identificadores de Classe A e B eram descritos como recursos cada vez mais escassos, exigindo alocação cuidadosa. O documento unia uma preocupação de capacidade a uma administrativa. Uma população global 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 a distribuição controlada, em vez do abandono imediato da autoridade central. O Internet Registry permaneceria o registro principal e o padrão onde nenhuma autoridade delegada existisse. Organizações aprovadas poderiam receber blocos e responsabilidade delegada. Cópias dos dados de registro agregados seriam distribuídas, enquanto as atualizações permaneceriam centralizadas.

RFC 1366, publicada em outubro de 1992, transformou a direção em regras mais específicas. Esperava-se que os registros regionais candidatos fossem reconhecidos em suas áreas geográficas, estáveis, adequadamente dotados de recursos e comprometidos com diretrizes comuns da IANA e do Internet Registry. As funções centrais retinham 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-redes documentando mais de 32 sub-redes e mais de 4.096 hosts. Ela permitia a consideração caso a caso quando um bloco de Classes C fosse tecnicamente inadequado. Para a Classe C, propunha blocos contíguos em nível de bits dimensionados de acordo com a necessidade e uma projeção de 24 meses.

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

A fonte canônica do períodoRIPE-048, publicada em 1º de agosto de 1992, mostra a interface europeia em desenvolvimento. Ela dizia que o RIPE NCC lidava com solicitações de organizações europeias e que os solicitantes geralmente devolveriam o material fornecido através de um provedor de serviços IP ou do RIPE NCC. Ela vinculava a alocação a relacionamentos com provedores e conectividade externa prospectiva.

A RIPE-048 afirmava que os números de Classe A e B eram escassos e exigiam justificativa em termos de tamanho e estrutura esperados da rede. Uma solicitação de Classe A exigia justificativa técnica detalhada e revisão global que poderia levar vários meses. Aconselhava o uso de um conjunto razoável de Classes C em vez de uma Classe B onde a rede pudesse ser construída dessa forma, observando explicitamente que isso revertia o conselho anterior motivado por restrições da 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 da RIPE-048 não reproduz essa folha. Portanto, seria impróprio atribuir uma lista detalhada de campos de hosts projetados, sub-redes e utilização à própria RIPE-048. O suporte direto é mais restrito: tamanho e estrutura esperados, provedor ou contexto de conectividade, adequação da Classe C, justificativa detalhada para a Classe A e a possibilidade de uma longa revisão global.

A RFC 1466, publicada em maio de 1993, fornece os campos detalhados diretamente. Esperava-se que um solicitante de Classe B documentasse mais de 32 sub-redes e mais de 4.096 hosts. O plano de engenharia tinha que explicar por que um bloco de Classes C era irrazoável e incluir o número de hosts esperados dentro de 24 meses e o número de hosts por sub-rede dentro desse 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 requisitos de endereço, não a capacidade prática de 254 hosts usada no exemplo de abertura. Essa distinção reflete a própria escada de alocação do documento e não deve ser silenciosamente “corrigida” para uma convenção diferente.

A política permitia ajustes para a topologia. Uma organização com 600 hosts distribuídos igualmente por dez Ethernets poderia receber dez Classes C, uma por LAN, se apoiasse o desvio com um plano de engenharia. Os registros também podiam solicitar uma explicação quando a falha em criar sub-redes de redes Classe C consumisse espaço excessivo.

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

Os casos limítrofes impedem um conto moral

As medições agregadas podem sustentar várias histórias simplistas se suas limitações forem ignoradas. Os casos nomeados são valiosos porque enfraquecem essas histórias sem fingir revelar motivos não documentados.

O intervalo BBN desafia a proposição de que titulares proeminentes invariavelmente recebiam uma classe grosseira. Em janeiro de 1983, as “redes locais BBN” representavam 1.024 das 1.042 unidades Classe C no total da fonte. Quatro Classes B teriam fornecido a mesma capacidade numérica bruta com quatro unidades classful. No entanto, o registro exibia a classe fina em massa.

Isso não prova que os administradores preferiam a alocação de granulação fina para a BBN. A justificativa original está ausente. O intervalo pode ter apoiado testes, redes locais separadas, experimentação ou propósitos administrativos internos. Seus membros podem não ter todos aparecido como rotas globais independentes. A descoberta defensável é simplesmente que a proeminência institucional não se mapeava mecanicamente para uma atribuição de classe grande.

Bristol desafia uma alegação diferente. 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 exclui uma proposição absoluta de que classes legadas de tamanho médio estavam fechadas para universidades não americanas.

Isso não estabelece tratamento igualitário. A solicitação está ausente e não há um grupo pareado de universidades malsucedidas. O caso prova que tal resultado ocorreu, não com que frequência ou por quê.

A rede 35 da Merit fornece um caso limítrofe operacional. A RFC 1166 listou a rede 35 entre as alocações de Classe A.RFC 1482, publicada em julho de 1993, mostrou-a configurada no backbone T3 da NSFNET de modo que anúncios de roteamento pudessem ser esperados de até seis sistemas autônomos.

Essa configuração de 1993 não estabelece a justificativa para a alocação original. Ela mostra que um único número de rede classful poderia, mais tarde, desempenhar um papel operacional semelhante à agregação em um ambiente roteado substancial. Um teste de utilização retrospectivo baseado apenas na contagem de hosts ativos omitiria essa função de roteamento.

Esses casos restringem, em vez de provar, a tese. Grandes atribuições não eram necessariamente irracionais. Coleções de pequenas redes não estavam confinadas a solicitantes marginais. Universidades não americanas não eram categoricamente excluídas da Classe B. Um grande número de rede poderia ter um papel de roteamento além do número de hosts visíveis em um determinado momento.

A falseabilidade aqui funciona removendo alegações universais. Ela não fornece os arquivos de decisão ausentes. BBN, Bristol e Merit devem ser tratados como casos limítrofes contra explicações simplistas, não como janelas para o raciocínio original do administrador.

Quatro pressões apareceram em relógios diferentes

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

A escassez de espaço de endereçamento finito dizia respeito ao espaço de 32 bits limitado e, mais imediatamente, aos inventários limitados de números de rede Classe A e Classe B. Uma Classe A englobava (2^{24}) valores numéricos de endereço local e consumia um dos cerca de 126 slots comuns de número de rede reconhecidos nas tabelas do período. A RFC 1466 relatou apenas cerca de 11 números de Classe A como não atribuídos ou não reservados sob suas definições de política e reservou a metade superior do espaço de Classe A indefinidamente.

A escassez de estado de roteamento dizia respeito à memória, processamento, atualizações de protocolo e estabilidade operacional. Ela poderia se tornar aguda enquanto grandes porções do espaço de endereçamento numérico permaneciam não atribuídas. Cada Classe C separadamente visível poderia 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-redes poderia parecer operacionalmente mais barata do que várias redes menores.

A necessidade no nível do solicitante era diferente novamente. A organização de 300 hosts não experimentava o pool IPv4 completo como abundante. Ela experimentava uma classe disponível como 46 endereços de host comuns muito pequena e a seguinte como muito maior do que o necessário. Duas Classes C resolviam a capacidade, mas introduziam possíveis custos de roteamento e coordenação. A escassez do solicitante era a falta de uma unidade de alocação bem ajustada.

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 rápido crescimento e à internacionalização. A RFC 1466 dizia que a demanda havia aumentado significativamente em dois anos e que a alocação precisava de uma abordagem mais sistemática. A RIPE-048 advertiu que a revisão global de uma solicitação de Classe A poderia levar vários meses.

Essas pressões não se moviam juntas. As tabelas de roteamento podiam crescer rapidamente, mesmo que milhões de números de rede Classe C permanecessem teoricamente disponíveis. Um pequeno solicitante poderia encontrar um limite de classe severo enquanto a exaustão numérica total permanecia distante. Um registro central poderia enfrentar uma carga de trabalho crescente, mesmo que cada formulário individual fosse fácil. Uma política projetada para conservar números de Classe B poderia 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 específico. O projeto das classes determinava as unidades disponíveis. As restrições de roteamento alteravam seus custos operacionais relativos. As instituições administrativas decidiam como distribuir autoridade e avaliar exceções. Os solicitantes forneciam previsões incompletas e escolhiam quais pedidos fazer.

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

As alternativas viáveis tinham todas custos

Uma contrafactual de período deve 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 poderia 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ço, quatro Classes C eram dramaticamente melhores. Em um sistema de roteamento classful, elas poderiam exigir quatro entradas de rede externamente visíveis. O conselho da RFC 1118 de que um campus anunciasse no máximo duas redes discretas tornava esse custo material em 1989.

A primeira alternativa viável era alocar múltiplas 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 acomodar equipamentos que não faziam sub-redes. Seus custos incluíam registro adicional, configuração e potencialmente rotas globais. O crescimento futuro poderia desencadear outra solicitação ou renumeramento.

A segunda alternativa era alocar uma Classe B e exigir a criação de sub-redes internas. Isso conservava o estado de roteamento externo e dava à organização um espaço considerável para crescimento. Seus custos eram uma reserva muito maior de valores de endereço numéricos e a dependência de hosts e gateways capazes de sub-redes. Durante um período de implementações mistas de 4.2BSD, 4.3BSD e outras, a compatibilidade era uma preocupação operacional, não uma ficção administrativa.

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

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

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

A ponte transparente poderia fazer várias LANs parecerem uma única rede, mas movia a complexidade para um domínio maior de camada de enlace. 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 provedor poderia distribuir a atenção administrativa sem alterar o formato do endereço. Blocos de números de Classe C poderiam ser delegados a organizações mais próximas dos solicitantes. Isso poderia encurtar os caminhos de comunicação, melhorar o serviço em idioma local e transferir a revisão de rotina para longe do registro central.

A delegação também criava custos. Os órgãos centrais e regionais precisavam de registros consistentes, critérios comuns e procedimentos de atualização confiáveis. Alguém tinha que decidir qual instituição regional possuía legitimidade, recursos e neutralidade. A RFC 1366 e a RFC 1466 dedicaram atenção substancial a essas qualificações porque a delegação transferia autoridade consequente, em vez de meramente trabalho postal.

Outra possibilidade era exigir renumeramento ou recuperação mais frequentes. Isso poderia ter recuperado capacidade não utilizada, mas teria imposto custos a hosts, gateways, controles de acesso, documentação, redes correspondentes e equipe operacional. A recomendação de continuidade da RFC 820 mostra que a dificuldade de renumeramento já era reconhecida. Uma regra que ignorasse esses custos conservaria valores de endereço exportando disrupção para os operadores.

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

• Múltiplas Classes C conservavam valores de endereço, mas podiam consumir rotas e transações administrativas.
• Uma Classe B com sub-redes conservava o 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.
• O renumeramento recuperava capacidade ao custo da continuidade operacional.

O sistema observado não era o único sistema tecnicamente possível. Era uma resposta a custos que não podiam ser todos minimizados ao mesmo tempo.

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

As evidências apoiam uma divisão de causalidade alocada.

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

O roteamento e o hardware tornaram as descontinuidades econômica e operacionalmente significativas. Várias Classes C podiam conservar valores de endereço enquanto aumentavam os encargos de números de rede e roteamento. Uma Classe B com sub-redes podia conservar o estado externo, exigindo software adequado e consumindo uma alocação muito maior. Essas eram restrições visíveis para os engenheiros contemporâneos.

A política administrativa determinava como o sistema respondia. O material publicado inicial continha critérios de elegibilidade e prontidão de gateway, mas não reconstrói uma interface completa de seleção de classe. Em 1990–1993, o registro público explicitamente discutia escassez, delegação, limiares de host e sub-rede, projeções de 24 meses, planos de engenharia e exceções. O julgamento tornou-se mais estruturado sem desaparecer.

Os resultados no nível do solicitante permanecem subdeterminados. Os instantâneos disponíveis carecem de solicitações completas, recusas, alternativas, registros de utilização e explicações de decisão. Eles não podem estabelecer que os solicitantes tecnicamente capazes desfrutaram de acesso geralmente superior ou que os administradores favoreciam sistematicamente os titulares. Também não podem estabelecer que as grandes alocações iniciais eram justificadas em todos os casos.

Os instantâneos, no entanto, mostram um mecanismo plausível de dependência de trajetória. Uma vez que um destinatário implantava uma atribuição, o renumeramento impunha custos. A RFC 820 explicitamente reconhecia a dificuldade como uma razão para preservar um número quando uma rede experimental se tornava operacional. Uma grande atribuição inicial poderia, portanto, permanecer em vigor depois que os critérios para novas atribuições comparáveis se tornassem mais rigorosos.

O benefício deve ser descrito como uma opção, não como um dividendo medido. O destinatário poderia expandir internamente, continuar apresentando um destino classful, renumerar com menos frequência ou reter capacidade cuja aquisição posterior se tornou difícil. Se um determinado destinatário usou essas opções, as merecia ou antecipava sua importância posterior é uma questão empírica separada.

Evidências modernas confirmam a persistência sem resolver os motivos iniciais. Um estudo de 2017 sobre transferências de IPv4 relatadas descobriu que o espaço legado representava 63,82 por cento do espaço de endereço em sua amostra de transferência relatada. 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, redesignação, reestruturação organizacional ou gerenciamento complexo de endereços, em vez de uma venda.

Esse resultado é relevante apenas como uma verificação restrita. 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 precisa, se a alocação era justa ou o que um administrador inicial pretendia.

O valor monetário presente está ainda mais distante da decisão inicial. 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 de política, os custos de transação, a fragmentação, as dependências operacionais e a distinção entre registro e controle. Mais importante, substituiria a escassez posterior pelo motivo contemporâneo.

A conclusão histórica é, portanto, limitada, mas consequente. O IPv4 classful converteu a granularidade técnica em uma fronteira de decisão administrativa. Os limites de roteamento às vezes tornavam a unidade maior defensável. Os limites de equipamento às vezes tornavam a criação de sub-redes custosa. Os primeiros solicitantes e administradores operavam com previsões que não podem agora ser reconstruídas a partir de registros preenchidos. As políticas posteriores tornaram os critérios de balanceamento mais explícitos e transferiram 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. Ela nasceu porque cada resposta disponível impunha custos a uma parte ou sistema diferente, e alguém tinha que decidir qual custo aceitar.

Fontes

• RFC 790,Assigned Numbers
• RFC 791,Internet Protocol
• RFC 820,Assigned Numbers
• RFC 950,Internet Standard Subnetting Procedure
• RFC 1118,The Hitchhikers Guide to the Internet
• RFC 1122,Requirements for Internet Hosts—Communication Layers
• RFC 1166,Internet Numbers
• RFC 1174,IAB Recommended Policy on Distributing Internet Identifier Assignment
• RFC 1338,Supernetting: an Address Assignment and Aggregation Strategy
• RFC 1366,Guidelines for Management of IP Address Space
• RFC 1466,Guidelines for Management of IP Address Space
• RFC 1482,Aggregation Support in the NSFNET Policy-Based Routing Database
• RIPE-048,RIPE Internet Network Numbers Template
• Computer History Museum,Guide to the SRI ARC/NIC Records
• University of Bristol,25 Years of Internet at University of Bristol
• On IPv4 Transfer Markets: Analyzing Reported Transfers and Inferring Transfers in the Wild