IPv4 par classes et la naissance de la rareté administrative

Résumé

Un réseau nécessitant 300 adresses d'hôte ordinaires dépassait de 46 adresses la capacité pratique de 254 d'un réseau de classe C. La classe native suivante offrait 65 534 adresses d'hôte ordinaires, tandis que deux classes C offraient 508 au prix possible d'une route supplémentaire et d'une coordination accrue. La géométrie par classes faisait donc de l'attribution un choix entre des coûts différents plutôt qu'une simple lecture de la demande en hôtes.
Trois instantanés contemporains montrent que les réseaux de classe C dominaient en nombre d'unités de numéros de réseau attribués, tandis que les attributions de classe A dominaient en capacité d'adresses représentée. En janvier 1983, 31 attributions de classe A représentaient 99,648 % des valeurs numériques d'adresses couvertes par les totaux publiés; 1 042 classes C représentaient 0,051 %.
Le matériel conservé ne fournit pas un échantillon apparié des premières demandes, refus et décisions. Il ne peut établir un effet général de précurseur, un accès inégal des demandeurs ou les critères utilisés dans une décision de classe précoce particulière. Il étaye une conclusion plus étroite: des attributions durables effectuées avant que des critères ultérieurs ne deviennent explicites pouvaient créer une option avantageuse plausible dépendante du chemin.
La rareté de l'espace d'adresses, la croissance de l'état de routage, le problème de dimensionnement d'un demandeur individuel et l'attention administrative limitée étaient des contraintes distinctes. Elles sont apparues à des moments différents et orientaient souvent vers des choix d'attribution différents.
Des classes C multiples, le sous-réseautage, des blocs contigus et la délégation régionale étaient des alternatives praticables à l'époque, mais chacune imposait des coûts de routage, matériels, de coordination ou administratifs. Une contrefactuelle équitable ne peut supposer que le routage sans classes était disponible tout au long des années 1980.

Un planificateur de réseau s'attendant à 300 hôtes ordinaires rencontrait une discontinuité précise. Un réseau de classe C contenait 256 valeurs possibles dans son champ d'adresse locale de huit bits. Selon les restrictions clarifiées ultérieurement sur les valeurs d'hôte tout à zéro et tout à un, il fournissait 254 adresses d'hôte ordinaires. Le besoin dépassait donc une classe C de 46 adresses, et non de deux. Le nombre deux décrit la différence entre 256 valeurs numériques et 254 adresses d'hôte ordinaires; il ne décrit pas le déficit par rapport à un plan de 300 hôtes.

Deux réseaux de classe C pouvaient couvrir le besoin immédiat avec 508 adresses d'hôte ordinaires. Cependant, ils restaient deux réseaux par classes, pouvant nécessiter deux entrées de routage visibles de l'extérieur, deux enregistrements et une coordination locale supplémentaire. La classe native suivante, la classe B, fournissait 65 536 valeurs numériques d'adresses locales, soit 65 534 adresses d'hôte ordinaires. Cela représentait environ 258,008 fois la capacité pratique d'hôtes d'une classe C et plus de 218 fois le besoin déclaré de 300 hôtes.

Le protocole ne contenait pas de classe intermédiaire. Il ne déterminait pas si la conservation des valeurs d'adresses était plus importante que la conservation de l'état de routage, si le matériel de l'organisation pouvait sous-réseauter en toute sécurité, si deux réseaux plus petits pouvaient être coordonnés sans perturbation, ou quelle croissance devait être prise en compte. Ces questions devaient être résolues en dehors du motif binaire.

C'est le point où la granularité technique est devenue une rareté administrative. La rareté n'a pas commencé uniquement lorsque le pool restant approchait de l'épuisement. Elle apparaissait aussi chaque fois que le besoin d'un demandeur tombait dans le large fossé entre les unités disponibles et qu'un administrateur devait déterminer quel coût le système d'attribution accepterait.

La géométrie a créé une frontière de décision

RFC 791, publiée en septembre 1981, définissait une adresse Internet comme quatre octets, soit 32 bits. Ses bits de poids fort sélectionnaient l'un des trois formats d'adresses ordinaires et fixaient ainsi la division entre le numéro de réseau et l'adresse locale.

Classe contemporaine	Motif de bits de poids fort	Bits de numéro de réseau après le motif	Bits d'adresse locale	Valeurs numériques dans un réseau	Adresses d'hôte ordinaires selon les règles clarifiées ultérieurement	Traduction moderne
Classe A	`0`	7	24	16,777,216	16,777,214	/8
Classe B	`10`	14	16	65,536	65,534	/16
Classe C	`110`	21	8	256	254	/24

La notation en barre oblique n'est incluse qu'à titre de traduction moderne des frontières de classes fixes. Il ne faut pas l'interpréter rétrospectivement comme la preuve qu'un administrateur en 1981 pouvait attribuer une longueur de préfixe arbitraire. Une classe B n'était pas un point sur un menu continu. Ses bits de tête indiquaient aux implémentations par classes de traiter les deux premiers octets comme la partie réseau. Une classe C fixait la frontière après trois octets. Le système n'offrait pas nativement une attribution routable globalement à mi-chemin entre les deux.

Le rapport de capacité numérique d'une classe à la suivante était exactement de 256. Une classe A contenait \(2^{24}\) valeurs d'adresses locales, une classe B \(2^{16}\) et une classe C \(2^8\). Après exclusion des valeurs d'hôte ordinaires tout à zéro et tout à un, les rapports pratiques étaient légèrement plus grands:

\(16,777,214 / 65,534 = 256.007782\) capacités de classe B par classe A.
\(65,534 / 254 = 258.007874\) capacités de classe C par classe B.

Les exclusions doivent être datées. La RFC 791 a établi la géométrie des classes mais n'a pas publié de tableau moderne des hôtes utilisables. LaRFC 950, publiée en 1985, expliquait les significations spéciales des champs zéro et tout à un dans le contexte du sous-réseautage et des diffusions. LaRFC 1122stipulait en 1989 que les champs hôte, réseau et sous-réseau ne pouvaient pas prendre les valeurs tout à zéro ou tout à un, sauf dans des cas spéciaux définis.

Pour comparer les attributions, les valeurs numériques totales sont la mesure la moins dépendante des hypothèses: \(2^{24}\), \(2^{16}\) ou \(2^8\) par réseau. Pour reconstituer le problème de capacité d'hôtes ordinaires d'un demandeur selon les règles clarifiées ultérieurement, les chiffres familiers moins deux sont appropriés. Mélanger ces deux mesures produit des affirmations trompeuses, comme le démontre l'exemple des 300 hôtes.

Les motifs de bits de poids fort divisaient également l'ensemble de l'espace 32 bits de manière inégale. Les adresses commençant par0occupaient la moitié de toutes les chaînes binaires. Le motif10en occupait un quart. Le motif110en occupait un huitième. Les autres motifs de poids fort étaient réservés ou développés à d'autres fins, notamment la multidiffusion et l'expérimentation. Ainsi, un petit nombre de numéros de réseau de classe A contrôlait une énorme partie de l'espace d'adressage numérique, tandis que le stock beaucoup plus important de numéros de réseau de classe C occupait une fraction plus petite.

Cette distinction entre les unités de numéros de réseau et la capacité représentée est fondamentale. Un registre pouvait contenir des milliers d'entrées de classe C et seulement quelques dizaines d'entrées de classe A, faisant apparaître la classe C comme dominante en termes de charge de travail. Le même registre, mesuré en valeurs d'adresses numériques, pouvait être massivement concentré en classe A. Aucun des deux dénominateurs n'est intrinsèquement faux. Ils répondent à des questions différentes.

Le décompte des numéros de réseau approxime le nombre d'unités par classes qui devaient être enregistrées et, lorsqu'elles étaient visibles de l'extérieur, routées. La capacité représentée mesure combien de valeurs d'adresses se trouvaient à l'intérieur des attributions listées. Aucun des deux n'est un décompte de demandeurs. Aucun ne mesure les hôtes actifs, l'utilisation, la visibilité de routage, la propriété organisationnelle ou la valeur économique.

L'architecture par classes produisait donc deux formes de grossièreté à la fois. Elle offrait trop peu de capacités intermédiaires aux demandeurs, et elle rendait la distribution apparente fortement dépendante de l'unité d'analyse de l'observateur. Le jugement administratif intervenait à la première frontière. Le jugement historique peut se tromper à la seconde.

Le routage rendait la plus grande unité opérationnellement attrayante

L'écart entre les classes B et C aurait été moins lourd de conséquences si les routeurs avaient pu agréger des réseaux adjacents arbitraires sans modifier leur interprétation. Pendant une grande partie de la période, ils ne le pouvaient pas.

L'architecture d'origine traitait Internet comme une hiérarchie de réseaux par classes. Une passerelle pouvait router sur la partie réseau tout en laissant le destinataire interpréter le champ d'adresse locale. Cet arrangement était économique lorsqu'un numéro de réseau correspondait raisonnablement bien à un réseau physique ou à une organisation. Il est devenu plus difficile à maintenir à mesure que les universités, les entreprises et les réseaux publics accumulaient des bâtiments, des réseaux locaux, des connexions point à point et des passerelles internes.

La RFC 950 décrivait trois grandes options pour une organisation disposant de plusieurs LAN. Elle pouvait obtenir un numéro de réseau Internet distinct pour chaque câble. Elle pouvait faire apparaître plusieurs LAN comme un seul réseau transparent. Ou elle pouvait diviser un réseau attribué unique en sous-réseaux.

La première option préservait des implémentations d'hôtes simples mais exportait la complexité locale dans le système de routage global. La RFC 950 avertissait que la propagation de chaque réseau local à l'échelle mondiale provoquerait une explosion de la taille des tables de routage, y compris sur les passerelles disposant de peu d'espace pour les informations de routage. Le pontage transparent évitait des numéros de réseau Internet supplémentaires mais apportait ses propres limitations en matière de passage à l'échelle et de domaines de défaillance. Le sous-réseautage permettait à un réseau par classes externe de contenir plusieurs réseaux internes, économisant les entrées de routage global au prix d'implémentations locales plus performantes.

L'arithmétique des sous-réseaux illustre pourquoi la classe B est devenue attrayante pour un campus en croissance. Si six bits de son champ local de 16 bits étaient utilisés pour les sous-réseaux, la géométrie brute produisait 64 motifs de sous-réseau et 1 024 motifs d'hôte dans chaque sous-réseau. Selon la convention de l'époque qui excluait les motifs de sous-réseau tout à zéro et tout à un, il restait 62 sous-réseaux ordinaires. En appliquant les exclusions habituelles d'hôtes, il restait 1 022 valeurs d'hôte par sous-réseau. Le produit était: \[62 \times 1,022 = 63,364\] Cette organisation pouvait exploiter des dizaines de réseaux internes derrière un seul numéro de classe B externe. L'arrangement utilisait bien plus de valeurs d'adresses que ce dont un petit campus avait initialement besoin, mais il économisait les numéros de réseau visibles de l'extérieur et laissait de la place pour la croissance interne.

Le sous-réseautage n'était pas sans coût. Les hôtes et les passerelles devaient comprendre les masques. Les attributions existantes dans le champ local pouvaient entrer en conflit avec une nouvelle frontière de sous-réseau. Le logiciel devait décider si une destination était locale ou nécessitait une passerelle en utilisant plus que la frontière de classe fixe.

Le guide opérationnel de 1989, laRFC 1118, décrivait directement le problème de compatibilité. De nombreux logiciels disponibles, notamment 4.2BSD, ne pouvaient pas gérer les adresses sous-réseautées sans logiciel supplémentaire, tandis que 4.3BSD prenait en charge le sous-réseautage dès sa sortie. D'autres systèmes variaient. Certains pouvaient fonctionner comme feuilles mais pas comme passerelles à l'intérieur d'une partie sous-réseautée du réseau.

La RFC 1118 donnait également au coût de routage une échelle concrète. Elle indiquait que certains nœuds importants ne pouvaient stocker et échanger des informations que pour environ 700 réseaux. Elle conseillait à un campus de ne pas annoncer plus de deux numéros de réseau distincts. Il était dit à un site s'attendant à dépasser cette limite d'envisager le sous-réseautage.

Le dilemme de l'allocateur n'était donc pas simplement « grand bloc contre petit bloc ». C'était un choix entre des ressources consommées à différents endroits:

Une classe B consommait une grande partie du pool d'adresses fini mais pouvait économiser des entrées de routage externe.
Plusieurs classes C économisaient les valeurs d'adresses numériques mais pouvaient ajouter des routes et un travail de coordination locale.
Le sous-réseautage économisait l'état externe mais nécessitait un équipement compatible et une compétence opérationnelle.
Reporter la décision n'économisait ni l'effort futur de renumérotation ni l'attention administrative si le demandeur dépassait rapidement l'attribution initiale.

La croissance de l'état de routage rendait le compromis de plus en plus urgent. LaRFC 1338reproduisait une série de Merit montrant 173 routes annoncées en juillet 1988, 603 en juillet 1989 et 4 775 en février 1992. La comparaison complète de juillet 1988 à février 1992 était: \[4,775 / 173 = 27.601\] C'était une augmentation de 27,601 fois sur 43 mois. La comparaison plus courte de juillet 1989 à février 1992 était: \[4,775 / 603 = 7.919\] C'était une augmentation de 7,919 fois sur 31 mois. Ce sont des comparaisons différentes et elles ne doivent pas être combinées.

La RFC 1338 soutenait que l'attribution de quatre à seize classes C au lieu d'une classe B pouvait ralentir l'épuisement des classes B mais aggraver la croissance des tables de routage, à moins que les protocoles de routage inter-domaines puissent représenter des agrégats arbitraires réseau-et-masque. Le remède proposé dépendait donc de plus qu'une simple nouvelle règle d'enregistrement. Les routeurs et les protocoles devaient transporter des informations qui ne correspondaient pas aux anciennes frontières de classes.

Le demandeur de 300 hôtes ressemble maintenant moins à un exercice d'arithmétique trivial. Deux classes C offraient une capacité immédiate suffisante, mais elles pouvaient nécessiter deux routes. Une classe B réduisait la représentation externe à un réseau tout en réservant 65 536 valeurs numériques. L'architecture créait la discontinuité. Le routage et l'équipement déterminaient les coûts relatifs. Le système administratif devait sélectionner une option imparfaite.

L'interface de décision précoce reste incomplète

La RFC 791 expliquait ce que signifiait une classe. Elle ne précisait pas qui devait en recevoir une. Cette décision a transité par un ensemble changeant d'institutions et de procédures.

En septembre 1981, laRFC 790publiait les numéros de réseau attribués et dirigeait les demandes d'attribution vers Jon Postel à l'Information Sciences Institute de l'Université de Californie du Sud. Le registre montrait les numéros attribués, réservés et non attribués, mais il ne publiait pas de test général complet pour choisir entre les classes A, B et C.

En janvier 1983, laRFC 820documentait un environnement politique plus élaboré. Elle étiquetait les attributions comme recherche et développement, défense ou commercial. Son annexe résumait les recommandations convenues entre le bureau du programme Defense Data Network et la DARPA en septembre 1982. Pour la communauté de la recherche, les recommandations liaient l'octroi d'identifiants de réseau à la preuve que le demandeur acquérait un logiciel de passerelle standard ou mettait en œuvre une passerelle répondant aux exigences du protocole de passerelle externe (EGP).

Ce critère concernait l'éligibilité et la préparation opérationnelle. Il ne fournissait pas de règle de dimensionnement complète. Il pouvait distinguer un demandeur prêt à participer à l'environnement réseau pertinent d'un autre sans capacité de passerelle adaptée, mais il ne disait pas à un administrateur si une organisation qualifiée planifiant 500 hôtes devait recevoir deux classes C ou une classe B.

La RFC 820 enregistrait également un écart de mise en œuvre entre la division prévue des responsabilités et le fonctionnement réel. La division proposée n'avait pas été pleinement mise en œuvre, et Postel restait le coordinateur des attributions de numéros. Les descriptions formelles de rôles et la gestion quotidienne étaient encore en train de converger.

L'arrangement institutionnel a changé au cours de la décennie. LeGuide des archives SRI ARC/NIC du Computer History Museumdate le transfert de l'administration des numéros attribués et de l'attribution mondiale des adresses IP de l'USC-ISI vers le contrat SRI NIC en 1987. L'instrument de recherche identifie de la correspondance et du matériel de nommage et d'adressage qui pourraient contenir des dossiers de demandes, mais il ne révèle pas lui-même le raisonnement derrière une décision de classe individuelle.

La RFC 1118 fournissait une description publique de la procédure destinée aux demandeurs en 1989. Un réseau connecté prospectif devait envoyer un message à[email protected], demander le modèle d'adresse connectée, le remplir et le renvoyer. L'adresse attribuée était ensuite renvoyée par courrier électronique ou postal. Le guide ajoutait qu'il restait peu de numéros de classe A et que, en pratique, la plupart des demandeurs devaient choisir entre la classe B et la classe C.

Cela établit qu'il y avait un formulaire, un canal de retour et un résultat. Cela ne reproduit pas les formulaires remplis et ne démontre pas quels champs déterminaient la classe sélectionnée dans un cas spécifique. Une description procédurale n'est pas un ensemble de données demande-décision.

La confirmation survivante envoyée à l'Université de Bristol est également limitée. L'université reproduit un message daté du 8 mars 1991 attribuant137.222.0.0, un réseau de classe B, àBRISTOL-NET. Il identifie la classe, le numéro, le contact technique et la date. Il conseille également le destinataire sur l'enregistrement de la table d'hôtes, l'adressage de diffusion et la résolution d'adresses.

La confirmation ne contient pas la demande soumise par Bristol, les prévisions d'hôtes, le plan de sous-réseau, les alternatives envisagées, les questions posées par le hostmaster ou les raisons du choix de la classe B. Elle prouve un résultat, pas la règle de décision de l'administrateur. C'est une réponse sans la demande et la délibération correspondantes.

Les preuves directes rassemblées ici ne reconstituent donc pas une paire complète de demande-réponse ou de demande-décision précoce. Les affirmations sur ce qu'un administrateur précoce a réellement vu doivent rester des hypothèses. Un administrateur plausible aurait pu prendre en compte les hôtes attendus, la topologie, les passerelles, le logiciel et la connectivité parce que ces questions étaient opérationnellement pertinentes et apparaissaient dans les directives publiques. Le matériel survivant ne démontre pas que tous ces éléments ont été soumis ou pondérés dans une décision précoce particulière.

La distinction est importante parce que les tables d'attribution complétées sont des preuves particulièrement tentantes. Elles montrent ce qui a été enregistré après approbation. Elles ne montrent pas la classe demandée, la taille initialement offerte, les prévisions du demandeur, un refus, une réduction, un retard ou un besoin non soumis. Déduire l'interface de décision à partir de la table complétée transformerait les résultats en motivations.

En août 1990, laRFC 1174décrivait les rôles institutionnels de manière plus formelle. La fonction IANA à l'USC-ISI conservait l'autorité centrale pour allouer et attribuer les identifiants numériques et l'autorité discrétionnaire pour déléguer des parties de cette responsabilité. La responsabilité des identifiants de réseau et de système autonome avait été confiée à l'Internet Registry géré par SRI International au DDN-NIC. Le document recommandait de conserver les fonctions centrales IANA et Internet Registry tout en déléguant des blocs à des organisations approuvées au niveau international.

Ces rôles ne doivent pas être confondus. La fonction IANA, l'Internet Registry, le service NIC et l'Internet Activities Board occupaient des positions liées mais distinctes. L'IAB émettait des recommandations. La fonction IANA détenait l'autorité d'allocation et de délégation. L'Internet Registry rassemblait et maintenait les enregistrements et traitait les attributions de numéros. Le demandeur rencontrait généralement le système par l'intermédiaire d'un hostmaster et d'un numéro retourné.

La RFC 1174 prouve que la discrétion et la délégation étaient des concepts institutionnels reconnus en 1990. Elle ne prouve pas comment la discrétion a été exercée dans un cas particulier de 1983 ou 1991.

Mesurer la distribution sans inventer des demandeurs

Une mesure reproductible peut être construite à partir d'instantanés publiés contemporains, à condition que son unité d'observation reste étroite.

L'unité utilisée ici est une unité de numéro de réseau par classes telle que comptée par la source citée. Ce n'est pas une organisation, un demandeur, un préfixe routé, un hôte, un détenteur actuel, un transfert ou une transaction économique. Si une source associe une plage contenant 1 024 réseaux de classe C à un seul nom, la mesure compte 1 024 unités par classes. Elle ne prétend pas que la plage représente 1 024 bénéficiaires.

Trois instantanés publiés fournissent des points de comparaison utiles:

Les totaux de janvier 1983 de la RFC 820 pour les numéros de réseau de classe A, B et C attribués.
LaRFC 1166, publiée en juillet 1990, et ses totaux pour les réseaux alloués pour Internet et les usages indépendants.
LaRFC 1466, publiée en mai 1993, et sa table intitulée « Network Number Statistics (May 1992) ».

Les plages réservées et non attribuées, les numéros de système autonome, l'espace multidiffusion et les classes expérimentales sont exclus. Les valeurs numériques représentées sont calculées en multipliant chaque décompte source par \(2^{24}\), \(2^{16}\) ou \(2^8\). Le calcul ne soustrait pas les réservations d'hôtes, de sous-réseaux ou de diffusion parce que les destinataires pouvaient structurer leurs champs locaux différemment et parce que le but est de mesurer la capacité numérique englobée par chaque attribution par classes.

Pour janvier 1983: \[(31 \times 16,777,216) + (24 \times 65,536) + (1,042 \times 256) = 521,933,312\]

Pour juillet 1990: \[(34 \times 16,777,216) + (2,533 \times 65,536) + (16,214 \times 256) = 740,578,816\]

Pour les statistiques de mai 1992: \[(49 \times 16,777,216) + (7,354 \times 65,536) + (44,014 \times 256) = 1,315,302,912\]

Instantané et définition de la source	Réseaux de classe A	Réseaux de classe B	Réseaux de classe C	Total unités par classes	Valeurs d'adresses numériques représentées	Part A	Part B	Part C
Janvier 1983, totaux attribués dans la RFC 820	31	24	1,042	1,097	521,933,312	99,648%	0,301%	0,051%
Juillet 1990, allocations Internet et indépendantes dans la RFC 1166	34	2,533	16,214	18,781	740,578,816	77,024%	22,415%	0,560%
Statistiques de mai 1992 reproduites dans la RFC 1466	49	7,354	44,014	51,417	1,315,302,912	62,501%	36,642%	0,857%

Les réseaux de classe C dominaient le décompte des unités de numéros de réseau dans les trois instantanés sélectionnés. Ils ne dominaient pas la capacité représentée. En janvier 1983, 31 attributions de classe A englobaient 99,648 % des valeurs d'adresses numériques dans les totaux publiés. Les 1 042 unités de classe C englobaient 0,051 %.

La première ligne contient une concentration importante. La RFC 820 associait la plage de192.1.xxxà192.4.xxxà « BBN local networks ». Chaque valeur complète du deuxième octet couvrait 256 numéros de réseau de classe C. Quatre de ces valeurs couvraient donc: \[4 \times 256 = 1,024\] Ces 1 024 unités représentaient: \[1,024 / 1,042 = 98.272553%\] du décompte de classe C dans le total de janvier 1983. Leur capacité numérique combinée était: \[1,024 \times 256 = 262,144\] Cela équivalait à quatre réseaux de classe B en capacité numérique brute: \[4 \times 65,536 = 262,144\]

La plage montre pourquoi les décomptes d'unités de réseau ne peuvent pas être lus comme des décomptes de bénéficiaires. Elle montre également que la classe sélectionnée n'était pas une fonction mécanique de la capacité numérique agrégée. Une organisation de premier plan pouvait apparaître comme une grande collection de petites unités par classes plutôt que comme un seul bloc grossier.

La table publiée ne dit pas pourquoi. Elle ne montre pas si les réseaux BBN étaient routés séparément, utilisés pour des tests, réservés à différents environnements locaux ou organisés selon un autre plan technique. Remplacer par quatre classes B dans une contrefactuelle préserve la capacité brute mais pas nécessairement la topologie, l'expérimentation, le comportement de routage ou la structure administrative prévue. La plage est donc une preuve contre une lecture simpliste une organisation/une classe, pas une preuve du raisonnement de l'administrateur d'origine.

La RFC 820 contient également des irrégularités de publication apparentes. Plusieurs lignes de classe C de défense répètent une valeur numérique alors que les totaux comptent des unités distinctes. Des numéros temporaires, des réseaux renommés et des entrées de transition apparaissent ailleurs. Les totaux propres de la source sont par conséquent plus sûrs pour une mesure agrégée qu'un décompte naïf des lignes visibles. Ils restent dépendants des définitions de la source.

L'instantané de 1990 introduit un dénominateur différent. La RFC 1166 rapportait séparément 4 210 réseaux attribués pour ARPA-Internet et DDN-Internet, et 18 781 alloués pour Internet et les usages indépendants. Le sous-ensemble connecté comprenait 29 classes A, 1 209 classes B et 2 972 classes C. Le total d'allocations plus large contenait 34 classes A, 2 533 classes B et 16 214 classes C.

Le total plus large est approprié pour mesurer la capacité par classes unique au niveau mondial mise en usage attribué ou alloué, y compris les réseaux indépendants. Le sous-ensemble connecté est plus proche d'un décompte des réseaux dans les environnements Internet spécifiés. Aucun des deux totaux n'est un décompte de demandeurs. Aucun ne révèle combien de demandes ont été refusées ou révisées.

Les sources de 1992 mettent en garde contre le fait de forcer les instantanés en une série continue faussement précise. La RFC 1338 rapportait qu'une analyse du fichiernetwork-contacts.txtdu DDN-NIC avait trouvé 46 classes A allouées et 5 467 classes B allouées le 25 février 1992. La RFC 1466 a reproduit plus tard les totaux de mai 1992 de 49 et 7 354. Les documents utilisaient également des dénominateurs de pool de classes B différents: 16 256 dans la RFC 1338 et 16 383 dans la RFC 1466.

Il serait imprudent d'interpréter toute la différence comme une poussée d'attributions sur trois mois. Les fichiers, les filtres, le traitement des plages réservées ou les significations de « alloué » ont pu différer. Sans les fichiers sous-jacents datés et leurs règles de transformation, l'écart ne peut pas être résolu à partir des deux totaux seuls. Les auteurs contemporains percevaient clairement une croissance rapide, mais cette perception ne rend pas des mesures différentes interchangeables.

Les noms des bénéficiaires ne réparent pas le dénominateur manquant

Attribuer une géographie est plus difficile que multiplier les décomptes de classes. Les premiers registres ne fournissaient pas de champ pays standard à côté de chaque réseau. Certains noms identifiaient explicitement un lieu ou une institution. D'autres décrivaient un projet, un système expérimental, un contractant ou un réseau transnational. Une adresse de contact pouvait identifier où l'administration avait lieu sans identifier chaque pays dans lequel le réseau fonctionnait.

Les entrées de classe A de la RFC 1166 comprenaient des cas clairement non américains, parmi lesquels RSRE au Royaume-Uni, CAN-INET au Canada et JAPAN-A avec un contact à l'Université de Tokyo. Les registres antérieurs incluaient University College London et des réseaux transatlantiques par paquets ou par satellite. Cela suffit à rejeter l'affirmation selon laquelle les attributions de grande classe étaient exclusivement américaines. Cela ne suffit pas à produire un pourcentage fiable par pays.

Un réseau satellite transatlantique résiste à l'attribution à un seul pays. Une entreprise peut opérer dans plusieurs juridictions. Un nom de projet peut survivre à son emplacement institutionnel d'origine. Les enregistrements ultérieurs du registre peuvent refléter des fusions, des transferts, des réorganisations ou des contacts modifiés. La géographie actuelle ne peut pas être projetée en arrière comme géographie du bénéficiaire d'origine sans une chaîne documentée.

Les noms changent également l'unité d'observation. Plusieurs entrées peuvent appartenir à une seule organisation; une entrée peut prendre en charge plusieurs organisations ou sites d'exploitation. La plage de classe C de BBN est l'exemple le plus clair de nombreuses unités de numéros de réseau sous un même nom. L'utilisation ultérieure par Merit du réseau 35 à travers plusieurs systèmes autonomes illustre le problème inverse: un réseau par classes pouvait participer à un arrangement de routage distribué.

L'absence de demande infructueuse est plus grave. Les registres publiés montrent principalement des attributions réalisées. Ils ne divulguent pas la population complète des demandeurs. Les observations manquantes peuvent inclure:

les demandes renvoyées pour informations complémentaires;
les demandes accordées dans une classe plus petite que celle initialement demandée;
les demandes retardées ou abandonnées;
les organisations orientées vers un fournisseur ou un autre registre;
les réseaux qui utilisaient une numérotation privée ou non unique;
les organisations qui ne connaissaient pas la procédure pertinente;
les demandeurs dissuadés par les exigences de passerelle, de connectivité ou d'équipement;
les bénéficiaires retenus dont les formulaires originaux ne subsistent plus.

Sans ce dénominateur, les instantanés ne peuvent pas mesurer les taux d'approbation, les retards, l'accès inégal ou l'avantage de précurseur au niveau du demandeur. Ils ne peuvent pas montrer si des demandeurs techniquement similaires ont reçu des classes différentes. Ils ne peuvent pas établir que la capacité d'ingénierie d'une organisation rendait le succès plus probable.

Les données peuvent établir la grossièreté, la concentration et la distribution changeante des unités par classes. Elles peuvent identifier un mécanisme par lequel des attributions précoces durables pourraient préserver des options ultérieures. Elles ne peuvent pas convertir ce mécanisme en un effet social mesuré sans demandes et résultats appariés.

Cette limite change le langage de la conclusion. « Les premiers bénéficiaires avaient un meilleur accès » nécessiterait des preuves sur des demandeurs comparables. « Les administrateurs favorisaient les titulaires capables » nécessiterait des preuves sur les décisions et les alternatives. L'affirmation défendable est conditionnelle: si une organisation a reçu et déployé une grande attribution avant que des critères plus stricts ne soient publiés, le coût de la renumérotation pouvait lui permettre de conserver un ensemble d'options qu'un demandeur ultérieur pourrait ne pas recevoir dans les mêmes conditions.

C'est une dépendance au chemin plausible. Ce n'est pas un dividende de précurseur quantifié.

Les critères publics sont apparus à mesure que la pression s'accumulait

L'interface précoce incomplète ne doit pas être confondue avec une absence de tout critère. Le dossier montre quelques règles d'éligibilité précoces et des directives d'attribution ultérieures beaucoup plus explicites.

Le critère de recherche de la RFC 820 liait l'attribution de numéros à l'état de préparation de la passerelle. Il recommandait également la continuité lorsqu'un réseau expérimental devenait opérationnel: si la renumérotation causait des difficultés, le réseau pouvait conserver son identifiant pendant que sa catégorie administrative changeait. C'était une reconnaissance explicite que le déploiement créait des coûts de changement. Cela ne montre pas que les administrateurs anticipaient une valeur de marché future. Cela montre que la continuité importait déjà sur le plan opérationnel.

En 1990, la RFC 1174 utilisait directement le langage de la rareté. La croissance rapide et l'internationalisation rendaient une délégation supplémentaire opportune, et les identifiants de classe A et B étaient décrits comme des ressources de plus en plus rares nécessitant une attribution prudente. Le document joignait une préoccupation de capacité à une préoccupation administrative. Une population mondiale de demandeurs dépendait de fonctions encore centrées dans des institutions américaines, tandis que le nombre de réseaux et d'enregistrements augmentait.

La réponse proposée était une distribution contrôlée plutôt qu'un abandon immédiat de l'autorité centrale. L'Internet Registry resterait le registre principal et le registre par défaut là où aucune autorité déléguée n'existait. Des organisations approuvées pouvaient recevoir des blocs et une responsabilité déléguée. Des copies des données d'enregistrement agrégées seraient distribuées, tandis que les mises à jour resteraient centralisées.

LaRFC 1366, publiée en octobre 1992, a transformé l'orientation en règles plus spécifiques. Les registres régionaux candidats devaient être reconnus dans leurs zones géographiques, stables, correctement dotés en ressources et engagés envers des directives communes de l'IANA et de l'Internet Registry. Les fonctions centrales conservaient la responsabilité de l'espace de classe B, les registres régionaux aidant à l'évaluation.

Pour la classe B, la RFC 1366 énonçait deux critères: un plan de sous-réseautage documentant plus de 32 sous-réseaux et plus de 4 096 hôtes. Elle autorisait une considération au cas par cas lorsqu'un bloc de classes C était techniquement inadapté. Pour la classe C, elle proposait des blocs contigus au niveau des bits, dimensionnés en fonction du besoin et d'une projection sur 24 mois.

Les critères rendaient certains facteurs publics tout en laissant une marge d'appréciation. « Plus de 32 sous-réseaux » dépendait d'une topologie proposée. « Plus de 4 096 hôtes » dépendait de ce qui comptait comme un hôte et si le nombre décrivait le déploiement actuel ou une croissance crédible. L'inadaptation technique nécessitait une explication plutôt qu'un calcul automatique.

La source canonique de l'époqueRIPE-048, publiée le 1er août 1992, montre l'interface européenne en développement. Elle indiquait que le RIPE NCC traitait les demandes des organisations européennes et que les demandeurs renverraient généralement le matériel fourni par l'intermédiaire d'un fournisseur de services IP ou du RIPE NCC. Elle reliait l'attribution aux relations avec les fournisseurs et à la connectivité externe prospective.

RIPE-048 indiquait que les numéros de classe A et B étaient rares et nécessitaient une justification en termes de taille et de structure de réseau attendues. Une demande de classe A nécessitait une justification technique détaillée et un examen global pouvant prendre plusieurs mois. Elle conseillait d'utiliser un ensemble raisonnable de classes C au lieu d'une classe B lorsque le réseau pouvait être conçu de cette façon, notant explicitement que cela inversait les conseils antérieurs motivés par les contraintes de table de routage.

Le document faisait référence à une feuille d'information distincte d'une page sur la classe B, mais le texte inspecté de RIPE-048 ne reproduit pas cette feuille. Il serait donc inapproprié d'attribuer une liste détaillée de champs de projection d'hôtes, de sous-réseau et d'utilisation à RIPE-048 lui-même. Le support direct est plus étroit: taille et structure attendues, contexte de fournisseur ou de connectivité, adéquation de la classe C, justification détaillée pour la classe A et possibilité d'un long examen global.

La RFC 1466, publiée en mai 1993, fournit directement les champs détaillés. Un demandeur de classe B était censé documenter plus de 32 sous-réseaux et plus de 4 096 hôtes. Le plan d'ingénierie devait expliquer pourquoi un bloc de classes C était déraisonnable et inclure le nombre d'hôtes attendus dans les 24 mois et le nombre d'hôtes par sous-réseau au cours de cette période. Les plans devaient rester confidentiels et être utilisés pour juger si la demande était justifiée. Un demandeur échouant au test recevrait un bloc de classe C, tandis que des exceptions restaient possibles.

Pour la classe C, la RFC 1466 établissait une échelle d'attribution contiguë basée sur la projection sur 24 mois de l'abonné:

Besoin projeté	Attribution par défaut
Moins de 256 adresses	1 classe C
Moins de 512	2 classes C contiguës
Moins de 1 024	4 classes C contiguës
Moins de 2 048	8 classes C contiguës
Moins de 4 096	16 classes C contiguës
Moins de 8 192	32 classes C contiguës
Moins de 16 384	64 classes C contiguës

Ces seuils utilisaient les besoins en adresses, et non la capacité pratique de 254 hôtes utilisée dans l'exemple d'ouverture. Cette distinction reflète l'échelle d'attribution propre du document et ne doit pas être silencieusement « corrigée » en une convention différente.

La politique autorisait un ajustement pour la topologie. Une organisation avec 600 hôtes répartis également sur dix Ethernets pouvait recevoir dix classes C, une par LAN, si elle soutenait la dérogation par un plan d'ingénierie. Les registres pouvaient également demander une explication lorsque l'absence de sous-réseautage des réseaux de classe C consommerait un espace excessif.

L'interface de décision de la période tardive était donc plus visible que celle du début. Les demandeurs savaient que les totaux d'hôtes, les plans de sous-réseau, un horizon de 24 mois et l'adéquation de la classe C importaient. Ils savaient aussi que des exceptions et le jugement du registre demeuraient. Le changement ne se faisait pas de la discrétion à l'absence de discrétion. Il allait de critères publics minces vers une discrétion structurée.

Les cas limites empêchent un conte moral

Les mesures agrégées peuvent soutenir plusieurs histoires simplistes si leurs limites sont ignorées. Les cas nommés sont précieux parce qu'ils affaiblissent ces histoires sans prétendre révéler des motifs non documentés.

La plage BBN remet en question la proposition selon laquelle les titulaires de premier plan recevaient invariablement une classe grossière. En janvier 1983, « BBN local networks » représentait 1 024 des 1 042 unités de classe C dans le total de la source. Quatre classes B auraient fourni la même capacité numérique brute avec quatre unités par classes. Pourtant, le registre affichait la classe fine en vrac.

Cela ne prouve pas que les administrateurs préféraient une attribution à granularité fine pour BBN. La raison d'origine est absente. La plage a pu soutenir des tests, des réseaux locaux séparés, de l'expérimentation ou des objectifs administratifs internes. Ses membres n'ont peut-être pas tous figuré comme des routes globales indépendantes. La conclusion défendable est simplement que la notoriété institutionnelle ne correspondait pas mécaniquement à une attribution de grande classe.

Bristol remet en question une autre affirmation. Une université européenne a reçu une classe B le 8 mars 1991, après que la croissance du routage était évidente et avant que les critères détaillés de 1992-1993 ne soient publiés. La confirmation écarte une proposition absolue selon laquelle les classes patrimoniales de taille moyenne étaient fermées aux universités non américaines.

Elle n'établit pas un traitement égal. La demande est manquante, et il n'y a pas de groupe apparié d'universités non retenues. Le cas prouve qu'un tel résultat s'est produit, pas à quelle fréquence ni pourquoi.

Le réseau 35 de Merit fournit un cas limite opérationnel. La RFC 1166 listait le réseau 35 parmi les attributions de classe A. LaRFC 1482, publiée en juillet 1993, le montrait configuré sur le backbone NSFNET T3 de sorte que des annonces de routage pouvaient être attendues de jusqu'à six systèmes autonomes.

Cette configuration de 1993 n'établit pas la justification de l'attribution d'origine. Elle montre qu'un seul numéro de réseau par classes pouvait ultérieurement jouer un rôle opérationnel de type agrégation dans un environnement routé substantiel. Un test d'utilisation rétrospectif basé uniquement sur le nombre d'hôtes actifs omettrait cette fonction de routage.

Ces cas contraignent, plutôt que de prouver, la thèse. Les grandes attributions n'étaient pas nécessairement irrationnelles. Les collections de petits réseaux n'étaient pas confinées aux demandeurs marginaux. Les universités non américaines n'étaient pas catégoriquement exclues de la classe B. Un grand numéro de réseau pouvait avoir un rôle de routage au-delà du nombre d'hôtes visibles à un moment donné.

La falsification fonctionne ici en supprimant les affirmations universelles. Elle ne fournit pas les dossiers de décision manquants. BBN, Bristol et Merit doivent être traités comme des cas limites contre les explications simplistes, et non comme des fenêtres sur le raisonnement original de l'administrateur.

Quatre pressions sont apparues sur des horloges différentes

Le mot rareté peut obscurcir plus qu'il n'explique à moins que la ressource contrainte ne soit nommée.

La rareté de l'espace d'adressage fini concernait l'espace 32 bits borné et, plus immédiatement, les stocks limités de numéros de réseau de classe A et de classe B. Une classe A englobait \(2^{24}\) valeurs d'adresses locales numériques et consommait l'un des quelque 126 créneaux de numéros de réseau ordinaires reconnus dans les tables de l'époque. La RFC 1466 ne signalait qu'environ 11 numéros de classe A comme non attribués ou non réservés selon ses définitions de politique et réservait indéfiniment la moitié supérieure de l'espace de classe A.

La rareté de l'état de routage concernait la mémoire, le traitement, les mises à jour de protocole et la stabilité opérationnelle. Elle pouvait devenir aiguë alors que de grandes parties de l'espace d'adressage numérique restaient non attribuées. Chaque classe C visible séparément pouvait ajouter une destination à la table d'un routeur. L'avertissement de la RFC 1118 concernant les nœuds limités à environ 700 réseaux et la série de routage de la RFC 1338 montrent pourquoi une classe B sous-réseautée pouvait sembler opérationnellement moins coûteuse que plusieurs réseaux plus petits.

Le besoin au niveau du demandeur était encore différent. L'organisation de 300 hôtes ne percevait pas l'ensemble du pool IPv4 comme abondant. Elle percevait une classe disponible comme trop petite de 46 adresses d'hôte ordinaires et la suivante comme bien plus grande que nécessaire. Deux classes C résolvaient le problème de capacité mais introduisaient des coûts possibles de routage et de coordination. La rareté du demandeur était un manque d'unité d'attribution bien adaptée.

L'attention administrative concernait la capacité à recevoir des formulaires, poser des questions, évaluer des plans, rapprocher des enregistrements, coordonner des délégations et renvoyer des décisions. La RFC 1174 liait une délégation supplémentaire à la croissance rapide et à l'internationalisation. La RFC 1466 indiquait que la demande avait augmenté de manière significative en deux ans et que l'attribution nécessitait une approche plus systématique. RIPE-048 avertissait que l'examen global d'une demande de classe A pouvait prendre plusieurs mois.

Ces pressions n'évoluaient pas ensemble. Les tables de routage pouvaient croître rapidement même si des millions de numéros de réseau de classe C restaient théoriquement disponibles. Un petit demandeur pouvait rencontrer une frontière de classe sévère alors que l'épuisement numérique total restait lointain. Un registre central pouvait faire face à une charge de travail croissante même si chaque formulaire individuel était facile. Une politique conçue pour conserver les numéros de classe B pouvait délibérément imposer plus de coûts d'équipement ou de routage aux demandeurs.

La séparation empêche également les raccourcis causals. L'existence d'un espace 32 bits fini ne dictait pas un régime administratif particulier. La conception des classes déterminait les unités disponibles. Les contraintes de routage modifiaient leurs coûts opérationnels relatifs. Les institutions administratives décidaient comment distribuer l'autorité et évaluer les exceptions. Les demandeurs fournissaient des prévisions incomplètes et choisissaient les demandes à faire.

La rareté n'était pas un événement unique. C'était un ensemble de contraintes désappariées.

Les alternatives réalisables comportaient toutes des coûts

Une contrefactuelle de l'époque devrait demander ce qui aurait pu raisonnablement être fait avec les protocoles, l'équipement et les institutions alors disponibles. Elle ne doit pas supposer qu'un administrateur en 1981 pouvait résoudre le problème en écrivant un préfixe arbitraire moderne dans un registre.

Considérons une organisation s'attendant à 1 000 hôtes ordinaires. Quatre classes C offraient: \[4 \times 254 = 1,016\] adresses d'hôte ordinaires. Une classe B en offrait 65 534. En termes de conservation d'adresses, quatre classes C étaient nettement meilleures. Dans un système de routage par classes, elles pouvaient nécessiter quatre entrées de réseau visibles de l'extérieur. Le conseil de la RFC 1118 selon lequel un campus ne devait pas annoncer plus de deux réseaux distincts rendait ce coût important en 1989.

La première alternative réalisable était d'attribuer plusieurs classes C et d'accepter les numéros de réseau supplémentaires. Cela ne nécessitait pas de nouveau format d'adresse. Elle conservait la capacité numérique et pouvait convenir à un équipement ne supportant pas le sous-réseautage. Ses coûts comprenaient des enregistrements, une configuration supplémentaires et potentiellement des routes globales. La croissance future pouvait déclencher une autre demande ou une renumérotation.

La deuxième alternative était d'attribuer une classe B et d'exiger un sous-réseautage interne. Cela conservait l'état de routage externe et donnait à l'organisation une marge de croissance considérable. Ses coûts étaient une réservation beaucoup plus importante de valeurs d'adresses numériques et une dépendance envers des hôtes et des passerelles capables de sous-réseautage. À une époque de mélange de 4.2BSD, 4.3BSD et d'autres implémentations, la compatibilité était une préoccupation opérationnelle plutôt qu'une fiction administrative.

Une troisième option était d'attribuer des classes C contiguës en préparation d'une agrégation ultérieure. La contiguïté aidait à préserver la possibilité de représenter plusieurs réseaux comme un seul préfixe une fois que les protocoles de routage et les routeurs prendraient en charge des informations réseau-et-masque arbitraires. Avant un tel support, le système par classes interprétait toujours les composants comme des réseaux de classe C individuels. La contiguïté seule ne faisait pas disparaître les entrées de routage.

La RFC 1338 rendait cette dépendance explicite. Son plan d'attribution proposé pouvait donner des blocs de classe C de taille appropriée à des organisations moyennes, mais l'avantage de routage nécessitait que les protocoles inter-domaines représentent des destinations réseau-plus-masque arbitraires. Les organisations multi-domiciliées pouvaient encore nécessiter des annonces plus spécifiques. Le déploiement exigeait des changements logiciels, une coordination opérationnelle et un accord entre le NIC, l'IANA et les fournisseurs de services.

Un sous-réseautage plus précoce était une autre réponse réalisable, mais il résolvait la topologie interne à l'intérieur d'une classe attribuée. Il ne réduisait pas la taille de la classe accordée. Une classe B sous-réseautée plaçait toujours 65 536 valeurs numériques sous une seule attribution. Diviser une classe A entre des organisations non liées aurait nécessité une couche de routage et d'administration partagée ou un support externe sans classes que l'architecture à deux niveaux d'origine ne fournissait pas.

Le pontage transparent pouvait faire apparaître plusieurs LAN comme un seul réseau, mais il déplaçait la complexité dans un domaine de couche liaison plus vaste. Il n'éliminait pas les coûts de défaillance, de performance ou de coordination. Il n'était pas un substitut universel aux sous-réseaux routés.

La délégation régionale ou basée sur les fournisseurs pouvait répartir l'attention administrative sans changer le format d'adresse. Des blocs de numéros de classe C pouvaient être délégués à des organisations plus proches des demandeurs. Cela pouvait raccourcir les chemins de communication, améliorer le service en langue locale et éloigner l'examen de routine du registre central.

La délégation créait également des coûts. Les organismes centraux et régionaux avaient besoin d'enregistrements cohérents, de critères communs et de procédures de mise à jour fiables. Quelqu'un devait décider quelle institution régionale possédait la légitimité, les ressources et la neutralité. Les RFC 1366 et RFC 1466 consacraient une attention substantielle à ces qualifications parce que la délégation transférait une autorité conséquente plutôt qu'un simple travail postal.

Une autre possibilité était d'exiger une renumérotation ou une récupération plus fréquente. Cela aurait pu récupérer de la capacité inutilisée, mais cela aurait imposé des coûts aux hôtes, aux passerelles, aux contrôles d'accès, à la documentation, aux réseaux correspondants et au personnel opérationnel. La recommandation de continuité de la RFC 820 montre que la difficulté de la renumérotation était déjà reconnue. Une règle qui ignorerait ces coûts conserverait les valeurs d'adresses en exportant la perturbation vers les opérateurs.

Chaque alternative tarifiait donc la rareté différemment:

Les classes C multiples économisaient les valeurs d'adresses mais pouvaient consommer des routes et des transactions administratives.
Une classe B sous-réseautée économisait l'état externe mais consommait une unité d'adresse grossière et nécessitait un équipement compatible.
Les classes C contiguës préservaient les options d'agrégation futures mais ne fournissaient pas de routage sans classes immédiat.
La délégation régionale répartissait l'examen mais nécessitait coordination, légitimité et cohérence des enregistrements.
La renumérotation récupérait de la capacité au prix de la continuité opérationnelle.

Le système observé n'était pas le seul système techniquement possible. C'était une réponse aux coûts qui ne pouvaient pas tous être minimisés simultanément.

Ce qui a changé, ce qui a persisté et ce qui ne peut être déduit

Les preuves soutiennent une répartition divisée de la causalité. La conception par classes a créé les discontinuités. L'adresse 32 bits aurait pu être divisée d'autres façons, mais l'architecture déployée offrait des frontières fixes A, B et C. Pour un besoin juste au-dessus de 254 hôtes ordinaires, il n'existait pas de classe native offrant une augmentation modeste. C'était une propriété du protocole.

Le routage et le matériel rendaient les discontinuités économiquement et opérationnellement significatives. Plusieurs classes C pouvaient économiser les valeurs d'adresses tout en augmentant les charges de numéros de réseau et de routage. Une classe B sous-réseautée pouvait économiser l'état externe tout en nécessitant un logiciel adapté et en consommant une attribution beaucoup plus grande. C'étaient des contraintes visibles pour les ingénieurs contemporains.

La politique administrative déterminait la réponse du système. Les premiers documents publiés contenaient des critères d'éligibilité et de préparation de passerelle mais ne reconstituent pas une interface complète de sélection de classe. Entre 1990 et 1993, le dossier public discutait explicitement de la rareté, de la délégation, des seuils d'hôtes et de sous-réseaux, des projections sur 24 mois, des plans d'ingénierie et des exceptions. Le jugement est devenu plus structuré sans disparaître.

Les résultats au niveau des demandeurs restent sous-déterminés. Les instantanés disponibles manquent de demandes complètes, de refus, d'alternatives, d'enregistrements d'utilisation et d'explications de décision. Ils ne peuvent pas établir que les demandeurs techniquement capables jouissaient d'un accès généralement supérieur ou que les administrateurs favorisaient systématiquement les titulaires. Ils ne peuvent pas non plus établir que les grandes attributions précoces étaient justifiées dans chaque cas.

Les instantanés montrent cependant un mécanisme plausible de dépendance au chemin. Une fois qu'un bénéficiaire déployait une attribution, la renumérotation imposait des coûts. La RFC 820 reconnaissait explicitement la difficulté comme une raison de conserver un numéro lorsqu'un réseau expérimental devenait opérationnel. Une grande attribution précoce pouvait donc rester en place après que les critères pour de nouvelles attributions comparables se soient resserrés.

L'avantage doit être décrit comme une option, pas comme un dividende mesuré. Le bénéficiaire pouvait s'étendre en interne, continuer à présenter une destination par classes, renuméroter moins souvent ou conserver une capacité dont l'acquisition ultérieure est devenue difficile. Qu'un bénéficiaire particulier ait utilisé ces options, les ait méritées ou ait anticipé leur importance ultérieure est une question empirique distincte.

Des preuves modernes confirment la persistance sans résoudre les motifs précoces. Une étude de 2017 sur les transferts d'IPv4 signalés a révélé que l'espace patrimonial représentait 63,82 % de l'espace d'adressage dans son échantillon de transferts signalés. La même recherche a montré pourquoi les enregistrements ultérieurs doivent être interprétés avec prudence: les changements de routage peuvent refléter des changements de fournisseur, des réaffectations, des restructurations organisationnelles ou une gestion d'adresses complexe plutôt qu'une vente.

Ce résultat n'est pertinent qu'à titre de vérification étroite. Il montre que les attributions de l'ère pré-registre ont persisté assez longtemps pour participer matériellement à la redistribution ultérieure. Il ne montre pas pourquoi une classe a été sélectionnée en 1983, si le demandeur d'origine a fourni une prévision exacte, si l'attribution était équitable ou ce qu'un administrateur précoce avait l'intention de faire.

La valeur monétaire actuelle est encore plus éloignée de la décision précoce. Un prix actuel appliqué à toutes les adresses à l'intérieur d'un bloc patrimonial ignorerait l'espace non routé, les restrictions politiques, les coûts de transaction, la fragmentation, les dépendances opérationnelles et la distinction entre enregistrement et contrôle. Plus important encore, cela substituerait une rareté ultérieure au motif contemporain.

La conclusion historique est donc bornée mais lourde de conséquences. L'IPv4 par classes a converti la granularité technique en une frontière de décision administrative. Les limites de routage rendaient parfois la plus grande unité défendable. Les limites d'équipement rendaient parfois le sous-réseautage coûteux. Les premiers demandeurs et administrateurs opéraient avec des prévisions qui ne peuvent pas être reconstituées aujourd'hui à partir des registres complétés. Les politiques ultérieures ont rendu les critères d'équilibrage plus explicites et ont déplacé le travail vers des institutions régionales et basées sur les fournisseurs.

La rareté administrative est née dans l'écart entre 254 et 65 534, mais pas parce que l'écart dictait une réponse unique. Elle est née parce que chaque réponse disponible imposait des coûts à une partie ou à un système différent, et quelqu'un devait décider quel coût accepter.

L'ère des adresses par classes et la naissance de la rareté administrative