La contrainte des 32 bits était technique; le régime de rationnement était politique

Résumé

• RFC 791a fixé chaque adresse IPv4 source et destination à 32 bits et a initialement interprété les adresses unicast ordinaires via trois classes; elle n’a pas prescrit de registres régionaux, de prévisions de demande, de tests d’utilisation, de dépendance envers les fournisseurs, d’audits, de sanctions ou de recours.
• Les 2^{32} valeurs possibles, soit 4 294 967 296, n’ont jamais constitué un réservoir unique d’adresses d’hôte publiques attribuables. La structure de classe, les valeurs spéciales, les réservations, les blocs alloués, la visibilité de routage et l’utilisation réelle ont créé différents dénominateurs qui ne peuvent pas être combinés.
• De 1993 à 1996, les directives publiées ont sélectionné des règles décisives: des prévisions sur 24 mois et des seuils de classe B dans la RFC 1466; l’agrégation basée sur la topologie dans la RFC 1519; et des allocations progressives, une hiérarchie de fournisseurs, des tests d’utilisation, des audits, la restitution d’adresses et des recours auprès du registre parent dans la RFC 2050.
• La conservation et l’agrégation répondaient à de véritables risques techniques, en particulier le gaspillage par classes et la croissance des tables de routage. L’élément politique ne résidait pas dans l’invention de la pénurie, mais dans le fait que des institutions identifiables ont choisi parmi des moyens possibles de répartir les coûts, l’autorité, les exceptions et les recours.
• Les registres publics d’allocation montrent les résultats positifs, pas les demandes, refus, révisions, retards ou conseils informels qui les ont produits. Le texte du régime et sa justification technique peuvent être reconstitués avec plus de confiance que son plein effet distributif.

L’architecture a fixé la limite; l’administration a choisi le test

Deux documents datés établissent la distinction essentielle.

En septembre 1981, la RFC 791 spécifiait un champ Adresse Source et un champ Adresse Destination, chacun de 32 bits. Elle définissait une adresse Internet comme quatre octets et divisait son interprétation unicast ordinaire initiale entre les formats de classe A, classe B et classe C. Une adresse de classe A utilisait un bit d’identification de classe, sept bits de numéro de réseau et 24 bits d’adresse locale. La classe B utilisait deux bits de classe, 14 bits de numéro de réseau et 16 bits d’adresse locale. La classe C utilisait trois bits de classe, 21 bits de numéro de réseau et huit bits d’adresse locale. Il s’agissait de caractéristiques du protocole, énoncées dans la discussion sur l’adressage et la spécification de l’en-tête.RFC 791, septembre 1981, sections 2.3 et 3.1, pages 7 et 11–12

En mai 1993, la RFC 1466 recommandait qu’un registre dimensionne des attributions contiguës de classe C à partir de la projection par le demandeur des adresses de système final nécessaires sur les 24 mois suivants. Une projection inférieure à 256 adresses correspondait à un numéro de réseau de classe C; inférieure à 512, à deux; inférieure à 1 024, à quatre; et ainsi de suite, jusqu’à 64 numéros de réseau de classe C contigus pour une projection inférieure à 16 384. Pour une classe B, le document indiquait qu’un demandeur devait justifier de plus de 32 sous-réseauxetde plus de 4 096 hôtes, étayés par un plan technique couvrant les 24 mois suivants.RFC 1466, mai 1993, sections 4.2.1 et 4.3, pages 6–8

La RFC 1466 était de nature informative. Son avis de statut indiquait expressément qu’elle ne spécifiait pas une norme Internet. Elise Gerich en est l’auteure; le résumé fait état d’un soutien général à ses recommandations de la part du Federal Engineering Planning Group agissant pour le Federal Networking Council, des co-présidents de l’Intercontinental Engineering Planning Group et de RIPE. Cette combinaison constitue la preuve d’une recommandation formulée par un auteur avec un soutien institutionnel. Elle ne prouve pas que chaque registre a immédiatement mis en œuvre chaque seuil, qu’une action normative de l’IETF a imposé la politique ou que chaque réseau concerné était d’accord.RFC 1466, statut, résumé et remerciements, pages 1 et 9

Le protocole et la recommandation répondaient à des questions différentes. Un champ de 32 bits définissait l’espace mathématique extérieur. Il ne choisissait pas un horizon de prévision, une hiérarchie d’allocation, une formule d’utilisation, une région géographique, un pouvoir d’audit ou une voie de recours. Les règles pouvaient être des réponses prudentes à des contraintes réelles, mais elles n’étaient pas déductibles de l’en-tête.

C’est le sens restreint depolitiqueici. Il identifie une décision prise par une institution nommée, auteure ou chargée de la mise en œuvre, parmi des arrangements techniquement et administrativement plausibles, où le choix a déplacé l’autorité ou imposé des coûts différents en matière de documentation, de délais, de dépendance envers les fournisseurs, de routage, de renumérotation ou de révision. Cela ne signifie pas que la pénurie a été fabriquée, que les acteurs étaient partisans ou que leurs choix étaient corrompus. Cela pose les questions de savoir qui a choisi la règle, quel paramètre alternatif aurait pu être retenu dans les conditions de l’époque, et sur qui ont pesé le fardeau ou l’autorité qui en ont résulté.

Un même espace d’adressage a produit plusieurs dénominateurs incompatibles

L’arithmétique familière est exacte:

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

Son unité est constituée de valeurs binaires nominales par champ d’adresse source ou destination de 32 bits. Ce n’est pas un décompte d’hôtes publics attribuables, d’organisations, de connexions clients, d’attributions de registres, de préfixes routés ou de demandes d’espace.

Les bits de classe ont immédiatement divisé cet espace mathématique. Le champ brut de numéro de réseau de classe A contenait 2^7 = 128 motifs binaires; la classe B en contenait 2^{14} = 16 384; et la classe C en contenait 2^{21} = 2 097 152. La comptabilité administrative ne traitait pas chaque motif brut comme un numéro de réseau ordinaire. Le tableau de mai 1992 de la RFC 1466 comptait plutôt 126 numéros de réseau de classe A, 16 383 de classe B et 2 097 151 de classe C. Ces chiffres représentent des populations de numéros de réseau par classes, et non des valeurs d’adresses ou des organisations.

Le tableau enregistrait également 49 numéros de réseau de classe A alloués, 7 354 de classe B et 44 014 de classe C en mai 1992. Il s’agit d’entrées réussies dans un tableau administratif particulier. Elles ne révèlent ni le nombre de demandeurs, ni combien d’adresses étaient occupées, annoncées, joignables ou demandées.RFC 1466, section 3, tableau 1, page 3

Un audit défendable des dénominateurs sépare donc les populations suivantes.

Ces distinctions ne sont pas du pinaillage sémantique. Chaque ligne répond à une question différente. Une allocation de premier niveau réduit un pool administratif sans montrer que l’espace alloué est annoncé. Une route peut couvrir un grand bloc avec peu de points terminaux occupés. Plusieurs routes peuvent représenter une seule allocation. Une assignation peut rester inutilisée, tandis qu’un hôte peut avoir plusieurs adresses ou interfaces. La RFC 791 elle-même envisageait des hôtes avec plusieurs interfaces physiques et plusieurs adresses Internet logiques. Un registre et une table de routage ne peuvent pas être fusionnés simplement parce qu’ils contiennent tous deux des préfixes.

La convention habituelle d’identification des hôtes de l’époque a créé encore une autre population. La RFC 1519 décrivait un réseau de classe C comme pouvant prendre en charge au plus 2^8 – 2 = 254 identifiants d’hôte ordinaires, et une classe B comme pouvant en prendre en charge au plus 2^{16} – 2 = 65 534, après exclusion des valeurs locales tout-zéro et tout-un utilisées selon la convention citée. Il s’agit d’identifiants ordinaires potentiels au sein d’un réseau, et non de comptages d’hôtes connectés.RFC 1519, norme proposée, septembre 1993, section 1, pages 1–2

Supposons, uniquement pour l’échelle, qu’un identifiant soit nécessaire pour chacun des 600 hôtes connectés. Les 65 534 identifiants ordinaires d’une classe B fourniraient 65 534/600 = 109,223 fois le besoin déclaré, laissant 65 534 – 600 = 64 934 identifiants ordinaires en dehors de ce besoin immédiat. Le calcul démontre la granularité par classes; il ne prouve pas qu’un vrai demandeur de 600 hôtes n’avait besoin d’aucune réserve, avait une topologie plate ou pouvait fonctionner avec un bloc sans classe arbitraire.

La RFC 1466 a proposé un exemple différent pour 600 hôtes. Si 600 hôtes étaient répartis également sur dix Ethernets et que la topologie rendait difficile l’utilisation d’un bloc de classe C partagé, le souscripteur pouvait recevoir dix numéros de réseau de classe C, un par Ethernet, sous réserve d’une justification technique pour s’écarter de la table par défaut en puissances de deux. L’unité considérée était alors des numéros de réseau de classe C, et non 600 adresses tirées d’un pool libre.RFC 1466, section 4.3, page 8

Les preuves ultérieures exigent la même prudence. L’étude de CAIDA sur la consommation d’IPv4 a été construite à partir d’un fichier IANA collecté le 14 septembre 2005 et d’instantanés WHOIS pris le 31 août 2005 pour ARIN, APNIC, LACNIC et RIPE. Il manquait un instantané AfriNIC. CAIDA a supprimé les différences de format pour créer une représentation commune et a limité les lignes de chaque RIR à l’espace associé à ce registre dans le fichier IANA, réduisant les apparitions en double causées par les migrations et les renvois. Elle a regroupé le matériel hérité migré dans un ensemble distinct « divers ».CAIDA, « IPv4 Consumption Rates », méthodologie et mises en garde

Ses chiffres utilisaient le volume d’adresses, couramment exprimé en quantités équivalentes/8. Ils distinguaient les allocations de l’IANA, la première occurrence dans un registre en aval et l’assignation la plus spécifique trouvée dans les données. CAIDA a expressément indiqué que les graphiques montraient des allocations, et non des annonces ou la joignabilité. Elle a également expliqué qu’un nettoyage de l’IANA avait attribué la date d’août 1993 à de nombreux enregistrements hérités pour lesquels les dates historiques précises n’étaient pas disponibles. Il s’agit de dates administratives reconstituées, et non de dates de transaction retrouvées.CAIDA, méthodologie, mises en garde et figures 1–7

La reconstitution est utile pour montrer pourquoi les niveaux administratifs doivent être séparés. Elle ne constitue pas une preuve contemporaine de l’expérience des demandeurs en 1993. Elle ne mesure pas les demandes, les refus, les révisions, les routes, les annonces, les hôtes joignables, les interfaces occupées, les motivations ou la causalité politique.

L’article de Richter, Allman, Bush et Paxson,A Primer on IPv4 Scarcity, est encore plus tardif. Il a été soumis le 10 novembre 2014, révisé le 27 février 2015 et publié en tant que contribution éditoriale dansACM Computer Communication Review45(2) en avril 2015. Il constitue une synthèse rétrospective précieuse et une piste de sources pour les développements techniques, institutionnels et de l’ère de l’épuisement. Il ne peut pas établir ce qu’un acteur savait en 1981–1998, comment un demandeur de l’époque a vécu l’interaction avec un registre, si un mécanisme a été déployé, ou si les contemporains adhéraient à une doctrine ultérieure de marché ou de propriété.Richter et al., « A Primer on IPv4 Scarcity », notice de publication

La limite mathématique extérieure était unique. La pénurie opérationnelle ne l’était pas. Elle se manifestait dans les décomptes de numéros de réseau par classes, les plages réservées, les détentions des registres, les unités d’assignation et l’état des routeurs, chacun avec sa propre date et son propre dénominateur.

Le gaspillage par classes et la pression sur le routage étaient réels

La première pression immédiate venait de la granularité. Une organisation nécessitant plus de 254 identifiants d’hôte ordinaires ne disposait pas d’une unité d’allocation par classes proportionnée à un besoin de 300, 600 ou 4 000. Une classe B pouvait être beaucoup trop grande. Un ensemble de classes C pouvait être plus proche en volume d’adresses, mais plus difficile à gérer et, avant une agrégation efficace, plus coûteux pour le système de routage mondial.

Le sous-réseautage aidait à l’intérieur d’un réseau par classes existant. La RFC 950, une spécification sur la voie de la normalisation d’août 1985, définissait un masque d’adresse qui divisait le champ d’adresse locale en parties sous-réseau et hôte. Une organisation pouvait utiliser un seul numéro de réseau reconnu extérieurement sur plusieurs sous-réseaux internes plutôt que d’annoncer chaque câble interne comme un réseau indépendant. Cela ne permettait pas à lui seul à un registre d’émettre des longueurs de préfixe routées mondialement arbitraires vers un Internet dont les mécanismes inter-domaines reposaient encore sur l’interprétation de classes.RFC 950, août 1985, section 2.1, pages 4–6

La deuxième pression venait de la table de transfert. Remplacer une ancienne attribution de classe B par 16 réseaux de classe C annoncés séparément pouvait préserver un numéro de réseau de classe B tout en ajoutant 16 entrées de routage là où l’agrégation n’était pas disponible. La conservation des adresses et la conservation du routage pouvaient donc aller dans des directions opposées.

La RFC 1519, publiée en tant que norme proposée en septembre 1993, décrivait trois problèmes: l’épuisement rapide des numéros de réseau de classe B, la croissance de la table de routage au-delà des capacités des logiciels et des routeurs disponibles, et l’épuisement futur de l’espace de 32 bits. Sa stratégie immédiate était le CIDR: attribuer des blocs contigus de taille plus appropriée, aligner la distribution sur la topologie, et annoncer des agrégats lorsque le support des protocoles et la connectivité le permettaient.RFC 1519, statut et sections 1–3, pages 1–9

Son argument quantitatif nécessite à la fois le tableau exact et le texte arrondi.

Le tableau I, provenant de MERIT, faisait état de 4 526 routes annoncées en janvier 1992 et de 8 561 en décembre 1992. La section 3.3.2 décrivait plutôt la base de données de routage NSFNET de janvier comme contenant « environ 4 700 » entrées et celle de décembre comme en contenant 8 500. Elle indiquait que le tableau historique avait doublé en moyenne tous les dix mois entre 1988 et 1991 et publiait une projection d’environ 30 000 entrées deux ans après la référence de janvier 1992.RFC 1519, tableau I et section 3.3.2, pages 7–9

Cette projection ne découle pas des entrées arrondies indiquées:

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

En utilisant l’observation exacte du tableau I de janvier, on obtient:

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

Aucun de ces résultats n’est environ 30 000 en arrondi ordinaire. L’article ne peut conserver 30 000 que comme la projection publiée et non réconciliée des auteurs de la RFC. La source n’explique pas la différence d’environ 5 193 entrées entre 30 000 et le résultat obtenu avec les entrées arrondies. Il serait inapproprié d’inventer une référence, un intervalle de croissance ou un ajustement caché différents pour combler l’écart.

La comparaison de décembre est plus directe. L’unité observée du tableau I était de 8 561 routes annoncées en décembre 1992. La section 3.3.2 arrondissait ce chiffre à 8 500 et le comparait à plus de 9 400 prédit par une courbe antérieure. Les auteurs disaient ne pas pouvoir déterminer si l’observation plus basse représentait un changement significatif de la croissance. Il s’agissait d’observations et de prévisions dans le contexte MERIT/NSFNET, pas d’un recensement de tous les routeurs ni d’une limite physique à laquelle l’Internet aurait échoué.

La RFC examinait également l’effet de l’émission de quatre à 16 routes de classe C là où une classe B aurait pu être utilisée auparavant. Elle projetait conditionnellement que la table de routage pourrait dépasser 10 000 entrées dans les six mois et 20 000 dans l’année. Il s’agissait de résultats de scénarios basés sur des réseaux de classe C annoncés séparément, et non de résultats observés. L’agrégation était destinée à empêcher précisément cette multiplication.

La logique technique était solide. Si les clients connectés via un même fournisseur recevaient des sous-ensembles contigus du bloc de ce fournisseur, le fournisseur pouvait annoncer une seule route moins spécifique. Dix blocs clients routés indépendamment pourraient nécessiter dix entrées visibles mondialement; dix blocs clients alignés sur la topologie pourraient, sous réserve d’exceptions et d’un fonctionnement correct, être couverts par un seul agrégat. L’économie exacte dépendait du multihébergement, de la politique de routage, des pannes, des filtres et de la nécessité de propager encore des routes plus spécifiques.

La transition n’était pas automatique. La RFC 1338, une proposition d’information publiée en juin 1992 et plus tard rendue obsolète par la RFC 1519, avertissait que le nouveau plan d’adressage et des modifications des protocoles de routage inter-domaines étaient nécessaires. Elle indiquait que les tables de routage pouvaient croître très rapidement dans l’intervalle entre le déploiement des allocations orientées topologie et le déploiement de protocoles compatibles.RFC 1338, juin 1992, section 2.1, page 4

BGP-4 fournissait une spécification pour le transport de préfixes sans classe et l’agrégation de routes, mais le statut de publication ne doit pas être confondu avec le déploiement. La RFC 1654 était une spécification BGP-4 sur la voie de la normalisation en juillet 1994. La RFC 1771, également sur la voie de la normalisation, l’a remplacée en mars 1995 et décrivait la prise en charge des préfixes IP, la suppression de la notion de classe de réseau dans BGP, et l’agrégation de routes et de chemins AS.RFC 1654, juillet 1994, statut et sections 1–2, pages 1–2;RFC 1771, mars 1995, statut et sections 1–2, pages 1–2

Ces publications établissent le statut de spécification et la capacité documentée. Elles n’établissent pas combien de routeurs exécutaient BGP-4 à une date donnée, quels réseaux échangeaient des routes sans classe, quelle partie de la table était agrégée, ou si l’adoption était universelle en 1998. Sans une série nommée d’instantanés de routage, une date d’observation, une population et un point d’observation, aucun taux de déploiement numérique ou affirmation « établie en 1998 » n’est justifié.

La règle de prévision répartissait l’incertitude

La règle de la classe B de la RFC 1466 expose le plus clairement le choix institutionnel. Ses critères indiqués exigeaient plus de 32 sous-réseauxetplus de 4 096 hôtes. Le demandeur devait également démontrer pourquoi un bloc de classes C était déraisonnable et fournir les nombres prévus d’hôtes et de sous-réseaux pour les 24 mois à venir. Si le plan ne justifiait pas une classe B, le résultat indiqué était un bloc de classes C. Un demandeur qui ne satisfaisait pas les critères numériques mais ne pouvait pas utiliser de classes C pouvait présenter un argument technique. Le document qualifiait ces seuils de critères suggérés plutôt que d’invariant protocolaire.RFC 1466, section 4.2.1, pages 6–7

L’objectif technique immédiat était la conservation des numéros de réseau de classe B. Selon la convention de l’époque, une classe B exposait 65 534 identifiants d’hôte ordinaires. Attribuer cette unité à un réseau ayant un besoin beaucoup plus faible pouvait bloquer une grande partie de sa capacité. Le plan de sous-réseau vérifiait si le demandeur avait besoin de la topologie qu’une classe B pouvait accueillir, plutôt que de simplement préférer sa commodité.

La RFC 1466 reconnaissait le fardeau. Elle indiquait que les restrictions sur les allocations de classe B pourraient obliger certaines organisations à consacrer des ressources supplémentaires à l’utilisation de plusieurs numéros de réseau de classe C. Le document considérait ce coût comme regrettable mais nécessaire pour poursuivre la conservation. C’est une preuve inhabituellement directe de l’incidence des coûts: la recommandation de l’auteur a choisi une règle de conservation et a identifié comme conséquence des dépenses techniques supplémentaires pour les demandeurs concernés.RFC 1466, section 4.2, page 6

L’horizon de 24 mois n’en était pas moins un paramètre. La RFC d’information documentait pourquoi les prévisions étaient nécessaires, mais elle ne démontrait pas que 24 mois minimisaient de manière unique le gaspillage total d’adresses, le coût de traitement, les délais ou l’erreur de prévision. Un test sur 12, 18 ou 36 mois serait une variante construite par l’analyste, à moins qu’une proposition directe de l’époque ne soit produite. De telles variations sont administrativement concevables, car le même demandeur pourrait soumettre les mêmes catégories de preuves techniques sur un horizon différent. Leurs performances pratiques restent inconnues: un horizon plus court réduirait l’exposition à une croissance optimiste mais augmenterait les demandes répétées, tandis qu’un horizon plus long pourrait réduire la fréquence des transactions au prix d’une erreur de prévision plus grande.

L’allocation sans classe était une alternative plus fondée techniquement en 1993, mais seulement dans certaines limites. La RFC 1338 avait proposé des blocs fournisseurs contigus en juin 1992, et la RFC 1519 spécifiait la stratégie d’assignation et d’agrégation CIDR en septembre 1993. Leurs propres avertissements montrent les hypothèses requises: les registres devaient allouer sur des frontières adaptées, les fournisseurs devaient maintenir des blocs alignés sur la topologie, et les protocoles inter-domaines et les routeurs devaient prendre en charge des paires réseau-masque arbitraires. Avant que ces conditions ne soient suffisamment mises en œuvre, l’émission de blocs plus fins pouvait multiplier les routes plutôt que les réduire.

La RFC 2050 a modifié la conception des prévisions en novembre 1996. Elle séparait les allocations aux FAI des assignations aux entreprises finales. La section 2.1 indiquait que les nouveaux FAI recevraient une allocation minimale basée sur les besoins immédiats. Les allocations ultérieures pourraient augmenter après que le FAI ait fourni une vérification de l’utilisation, et l’espace supplémentaire était destiné à couvrir environ trois mois d’assignations en aval. La clientèle projetée était réputée avoir peu d’effet; les besoins démontrés prévalaient.RFC 2050, BCP 12, novembre 1996, section 2.1, pages 4–5

Les fameux chiffres de 25 et 50 pour cent se trouvaient ailleurs. Ils figuraient dans la section 3.1, dans le cadre des assignations aux entreprises finales: un taux d’utilisation immédiate de 25 pour cent et un taux d’utilisation de 50 pour cent dans un délai d’un an. La section 3.6 définissait le numérateur comme le nombre d’hôtes connectés au réseau et le dénominateur comme le nombre total d’hôtes possibles sur ce réseau. Le critère d’un an signifiait donc que l’on attendait que les hôtes connectés atteignent au moins 50 pour cent de la population possible d’hôtes du réseau dans cet horizon. Il ne s’agissait pas d’un ratio clients/adresses, adresses assignées/taille de l’allocation, interfaces/adresses, ou assignations en aval/allocation FAI.RFC 2050, sections 3.1 et 3.6, pages 7 et 9

Cette distinction modifie l’analyse institutionnelle. Les entreprises finales étaient confrontées à un test d’utilisation basé sur les hôtes connectés par rapport aux hôtes possibles sur leur réseau proposé. Les FAI étaient confrontés à un démarrage progressif, à une utilisation avale vérifiée et à une quantité de réapprovisionnement destinée à couvrir environ trois mois d’assignations supplémentaires. Les combiner créerait une métrique commune fictive.

Les deux conceptions plaçaient l’incertitude des prévisions quelque part. Une attribution initiale plus longue exposait le pool commun si la demande ne se matérialisait pas. Une attribution initiale plus petite augmentait l’importance de la réactivité du registre et de la capacité du demandeur à documenter une croissance répétée. Les RFC établissent les règles choisies et leurs objectifs déclarés. Elles ne fournissent pas de distributions des délais de traitement, des montants initiaux demandés, des historiques de révision, ni la preuve qu’une classe de demandeurs a systématiquement subi plus de retards.

La hiérarchie a transformé la topologie en dépendance

La RFC 1466 proposait de diviser des portions de l’espace des numéros de classe C en grands blocs géographiques et de déléguer la responsabilité principale d’allocation à des registres régionaux qualifiés. Elle décrivait cette division comme « essentiellement une division administrative » destinée à soutenir l’enregistrement distribué. Elle privilégiait un registre régional unique à ce niveau, s’attendait à ce que l’organisation soit reconnue et dotée de ressources suffisantes, et exigeait un engagement envers les directives de l’IANA et du registre Internet central. Le registre central restait disponible pour servir un souscripteur si nécessaire, bien qu’il puisse le renvoyer vers l’organisme régional.RFC 1466, sections 2, 3 et 4.3, pages 2–4 et 7

Le plan d’ensemble liait l’administration distribuée à l’agrégation potentielle. Les blocs géographiques pouvaient réduire la charge de travail centrale et permettre des résumés grossiers lorsque la géographie et la topologie coïncidaient. Aucune de ces relations n’était garantie. Un continent n’était pas encodé dans l’en-tête IPv4, et la topologie physique ou celle des fournisseurs ne suivait pas nécessairement une frontière régionale.

Le choix d’un registre régional reconnu unique concentrait l’autorité d’interprétation sur les allocations locales, les preuves et les exceptions. Une base de données partagée avec des registres qui se chevauchent, ou un choix général du demandeur entre les décideurs centraux et régionaux, serait une alternative analytique plutôt qu’une proposition documentée de l’époque dans les sources utilisées ici. Sa faisabilité supposerait une coordination rapide des bases de données, des vérifications fiables de l’unicité, des règles d’allocation communes et un moyen d’empêcher des attributions concurrentes. Ces hypothèses étaient administrativement exigeantes en 1993. L’alternative est utile pour situer l’autorité, pas pour affirmer que des registres qui se chevauchent auraient donné de meilleurs résultats.

La RFC 1519 a déplacé la hiérarchie vers la topologie des fournisseurs. Elle recommandait que la plupart, sinon la totalité, des numéros de réseau soient distribués par l’intermédiaire des fournisseurs de services. Sa logique technique était directe: les adresses tirées du bloc d’un четыреnisseur pouvaient être représentées par l’agrégat de ce четыреnisseur, tandis que les blocs situés indépendamment exigeaient souvent des routes plus spécifiques. Le document avançait également que l’allocation distribuée réduisait la charge bureaucratique sur les autorités centrales de numérotation.RFC 1519, sections 2.2 et 3, pages 5–8

La RFC 2050 décrivait un système de registres à trois niveaux: l’IANA, les registres Internet régionaux et les registres Internet locaux. Dans le cadre des FAI, un FAI échangeant des routes en plusieurs emplacements sans routage par défaut pouvait demander de l’espace directement à son registre régional. Il était dit aux autres FAI de demander de l’espace à un fournisseur en amont. L’accès régional direct était associé au multihébergement ou à la connexion à un point d’échange neutre majeur, que la RFC définissait comme connectant quatre FAI non apparentés ou plus.RFC 2050, sections 1.1 et 2.1, pages 3–4

La même section encourageait les fournisseurs à traiter les assignations aux clients comme des prêts pendant la durée de la connectivité. Lorsqu’un client changeait de fournisseur, elle recommandait la restitution des anciennes adresses et la renumérotation dans l’espace du nouveau fournisseur, avec un délai de transition suffisant avant réutilisation. C’était une stratégie de routage ayant une conséquence en termes de coût de changement. L’espace provenant du четыреnisseur améliorait les possibilités d’agrégation; la continuité des adresses du client devenait dépendante de la relation avec le четыреnisseur.

Les coûts étaient déjà reconnus. La RFC 1900, une déclaration d’information de l’Internet Architecture Board en février 1996, indiquait que les organisations qui ne renumérotaient pas après avoir changé de fournisseur pourraient faire face à une connectivité limitée, à des coûts supplémentaires pour supporter la charge de routage qui en résulterait, ou les deux. Son titre,Renumbering Needs Work, résumait l’état de la technique. Elle appelait au développement et au déploiement de mécanismes pour faciliter les changements; elle ne rapportait pas que la renumérotation était devenue bon marché ou routinière.RFC 1900, février 1996, section 1, pages 2–3

Les décideurs et les responsables de la mise en œuvre nommés étaient les auteurs des RFC, les autorités de l’IANA et des registres, les registres régionaux et locaux, les fournisseurs qui attribuaient de l’espace et les réseaux de transit qui acceptaient ou filtraient les routes. L’alternative possible à l’époque n’était pas un adressage portable illimité. C’était un équilibre différent: plus d’allocations directes réduiraient la dépendance de certains clients à la renumérotation, mais, en l’absence d’une agrégation fiable ou d’une coordination sur l’acceptation des routes, pourraient ajouter des préfixes visibles mondialement. Les documents conservés prouvent la direction de l’arbitrage. Ils ne quantifient pas combien de clients ont renuméroté, combien ont conservé d’anciennes routes, ce qu’ils ont payé, ou avec quelle constance les fournisseurs ont fait respecter la restitution.

Le pouvoir d’audit existait sur le papier; sa pratique reste non mesurée

Le troisième choix institutionnel concernait la vérification et les conséquences.

La RFC 1466 permettait au registre Internet central de recevoir les plans comptables et techniques des allocations régionales déléguées et de vérifier la cohérence de ces plans avec les directives. Les exceptions aux critères de dimensionnement de la classe C devaient être décidées au cas par cas. Le document ne fournissait pas de registre des exceptions, de délai de réponse standard, de charge de la preuve publiée ou d’examinateur indépendant.RFC 1466, sections 4.2.2 et 4.3, pages 7–8

La RFC 2050 décrivait un ensemble de preuves plus étendu. Un registre pouvait exiger des masques de sous-réseau, des comptages d’hôtes, la topologie, des plans de routage, des calendriers de déploiement, les assignations antérieures et des corroborations. L’espace précédemment détenu par des divisions ou des filiales relevant d’une même entité mère pouvait être pris en compte au niveau de l’entreprise. Les demandes étaient traitées au cas par cas, l’efficacité du routage figurant parmi les considérations pertinentes.RFC 2050, sections 3.2–3.5, pages 8–9

La section 4 indiquait que toutes les demandes d’adresses étaient soumises à audit et vérification par tout moyen que le registre régional jugeait approprié. S’il s’avérait qu’une assignation reposait sur des informations fausses, le registre pouvait invalider la demande et restituer les adresses attribuées au pool libre. La section 3.1 précisait séparément qu’une adresse restait valide tant que les critères de qualification continuaient d’être remplis et réservait un pouvoir d’invalidation lorsque le besoin n’existait plus. La recommandation de restitution de la section 2.1 s’appliquait aux adresses de clients provenant du fournisseur lorsque la connectivité prenait fin. Il s’agissait de pouvoirs liés mais distincts: l’invalidation pour fausse information, l’examen de la persistance du besoin et la restitution lors d’un changement de fournisseur.RFC 2050, sections 2.1, 3.1 et 4, pages 4–5, 7 et 10

Le texte prévoyait également un examen hiérarchique. La section 6 permettait à une organisation insatisfaite du registre d’attribution de faire appel auprès du registre parent. La documentation pertinente devait être mise à disposition, et un appel supplémentaire pouvait remonter la chaîne jusqu’à l’IANA. Chaque registre était censé documenter sa procédure d’appel. L’examinateur restait dans la même hiérarchie de registres; la RFC ne créait pas de tribunal externe.RFC 2050, section 6, page 11

Ces dispositions autorisaient l’application et l’examen. Elles ne démontrent pas la pratique. Aucun fichier cité n’établit la fréquence des audits, les méthodes utilisées, si les demandeurs recevaient un préavis ou une possibilité de régularisation, comment l’erreur de prévision était distinguée d’une fausse déclaration, la fréquence des restitutions d’adresses, ou si un appel a modifié un résultat. Le texte ne peut pas démontrer la cohérence entre les registres ou dans des cas individuels.

Plusieurs variantes procédurales sont concevables avec la technologie de 1996 car elles modifient l’administration plutôt que les formats de paquets: motivation écrite des exceptions, protocole d’audit défini, période de préavis et de régularisation, statistiques anonymisées, ou examen par des responsables extérieurs à la chaîne de décision initiale. Ce sont des paramètres construits par l’analyste, à moins qu’une proposition datée ne soit produite. Elles exigeraient du personnel, une tenue de dossiers, des contrôles de confidentialité et une autorité convenue. Leurs coûts et leurs effets ne peuvent pas être estimés à partir de la seule RFC.

Le choix institutionnel était donc réel mais limité. La RFC 2050 donnait aux registres régionaux un pouvoir discrétionnaire sur la vérification et les conséquences énoncées, tout en plaçant l’examen dans la chaîne parente. Cette conception pouvait dissuader les fausses déclarations et préserver les enregistrements d’adresses. Elle concentrait également l’autorité d’enquête, d’exception et de sanction. Les preuves que cette autorité existait sont solides; les preuves concernant son invocation et ses effets distributifs sont absentes.

Le dossier RIPE prouve moins qu’un dossier d’attribution ne le ferait

L’épisode RIPE fournit la preuve d’un fonctionnement délégué, mais pas d’une décision d’allocation complète.

Le document RIPE-062,RIPE NCC Internet Numbers Registration Procedures, version 0.5 de juillet 1992, figure à l’annexe A du premier rapport trimestriel du RIPE NCC. Il indiquait que le RIPE NCC agissait depuis le 1er mai 1992 en tant que registre délégué pour les numéros de réseau Internet européens. Sa procédure consistait à fournir des numéros aux fournisseurs de services et aux organismes de coordination nationaux ou locaux plutôt que directement aux organisations individuelles. Il permettait aux fournisseurs de services de demander des numéros de réseau de classe B un par un et exigeait une justification basée sur la taille de l’organisation, le réseau existant, la croissance prévue et l’impossibilité d’utiliser un bloc de classe C.RIPE-062, version 0.5, juillet 1992, page 25 et suivantes

La section 3 de la RFC 1466 a par la suite enregistré deux faits plus étroits. Le RIPE NCC avait déjà reçu l’intervalle de numéros de réseau de classe C de 193.0.0 à 193.255.255 avant l’adoption de la proposition de la RFC, et il avait accepté d’allouer dans cet intervalle conformément aux directives de la RFC 1466.RFC 1466, section 3, page 3

L’intervalle contient 2^{16} = 65 536 numéros de réseau de classe C de taille/24. Exprimé sous la forme de l’intervalle CIDR ultérieur 193.0.0.0/8, il couvre 2^{32-8} = 16 777 216 valeurs d’adresse nominales. Le premier nombre compte des unités de numéro de réseau de classe C; le second compte les valeurs binaires couvertes par l’intervalle. Ni l’un ni l’autre ne mesurent les hôtes connectés, les attributions en aval, les annonces, l’utilisation ou la quantité demandée par le RIPE NCC.

Les documents conservés ne fournissent pas la demande sous-jacente, un acte d’attribution formel, une note de décision, les tailles de bloc alternatives envisagées, les conditions négociées ou une date d’attribution exacte. RIPE-062 prouve une procédure déléguée. La RFC 1466 prouve la possession antérieure du bloc 193.* et l’accord pour utiliser les nouvelles directives. L’administration distribuée et l’agrégation potentielle étaient des objectifs du plan politique d’ensemble; on ne peut pas affirmer qu’ils constituent le motif documenté ou la condition négociée de cette attribution particulière.

Le dossier ne contient pas non plus de dossier d’appel ou de révision concernant la délégation. Il permet de conclure, au niveau du registre, que la délégation fonctionnait en 1992. Il ne permet pas de tirer une conclusion au niveau des demandeurs sur les refus, les inégalités de traitement, les retards ou l’incidence d’un seuil.

Les réponses techniques sont arrivées par étapes

La période n’a pas offert un substitut complet au rationnement. Elle a offert des réponses partielles avec différents statuts, prérequis et transferts de coûts.

L’espace privé illustre la différence entre spécification et substitution. La RFC 1918, BCP 5 de février 1996, réservait trois blocs pour les réseaux privés. Elle exigeait d’une entreprise qu’elle détermine quels hôtes n’avaient pas besoin de connectivité externe au niveau réseau. Le passage d’un hôte du statut privé au statut public impliquait de changer son adresse IP, les entrées DNS correspondantes et les fichiers de configuration sur les autres hôtes qui faisaient référence à l’adresse. Les informations de routage privé ne devaient pas se propager au-delà des frontières de l’entreprise, et les références DNS privées nécessitaient un confinement.RFC 1918, février 1996, sections 2–5, pages 3–7

Le NAT était plus qu’un concept en mai 1994, mais moins qu’une solution universelle éprouvée. La RFC 1631 était informative et décrivait une conception préliminaire. La section 3 expliquait que les applications transportant une adresse IP dans leurs données pouvaient échouer à moins que le traducteur ne reconnaisse et ne réécrive le contenu; le chiffrement pouvait rendre cela impossible. La section 4 identifiait des mises en œuvre expérimentales dans le logiciel KA9Q et un routeur Cray Communications, testées avec Telnet et FTP, et indiquait que les prototypes ne démontraient la transparence que dans les limites énoncées par l’article.RFC 1631, mai 1994, sections 3 et 4, pages 6–9

IPv6 a changé le dénominateur architectural. La RFC 1883, une spécification sur la voie de la normalisation publiée en décembre 1995, a fait passer la taille de l’adresse IP de 32 à 128 bits. Elle n’a pas remplacé les hôtes, routeurs, applications ou procédures d’exploitation IPv4 installés à sa publication. Pour un registre traitant une demande IPv4 en 1996, IPv6 était un successeur spécifié, et non la preuve que le problème immédiat d’allocation IPv4 avait disparu.RFC 1883, décembre 1995, statut et section 1, pages 1 et 3

La récupération a également connu des étapes. La RFC 2050 recommandait la restitution des adresses provenant du fournisseur après la fin de la connectivité et autorisait l’invalidation dans des circonstances spécifiées. Elle ne contenait pas d’ensemble de données sur les blocs récupérés et n’établissait pas avec quelle facilité les réseaux opérationnels pouvaient les céder. La récupération était un mécanisme autorisé, pas une réponse mesurée de l’offre.

L’amélioration du matériel restait une possibilité conditionnelle. La RFC 2050 indiquait que les contraintes d’adressage reflétaient la technologie des routeurs, les pratiques d’assignation et l’histoire architecturale. Le document rapportait une conclusion de ses auteurs, du groupe de travail de l’IETF chargé de l’examen et de l’IESG selon laquelle aucune autre technologie déployable à l’époque ne surmontait ces limitations, tout en permettant un réexamen si les routeurs géraient ultérieurement des tables plus grandes et plus dynamiques ou si l’agrégation devenait possible par d’autres moyens. Il s’agit d’une évaluation institutionnelle contemporaine de la technologie, pas d’une référence pour chaque routeur et pas de la preuve que les paramètres de prévision, d’audit et d’appel qui l’accompagnaient étaient institutionnellement uniques.RFC 2050, introduction, page 2

La RFC 2050 représentait la pratique sans recevoir d’approbation politique

Le rôle institutionnel importe, car « l’IETF a décidé » amalgamerait plusieurs actes différents.

La RFC 2050 était le BCP 12, publié en novembre 1996, et avait pour auteurs Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg et Jon Postel. Son résumé décrivait les politiques alors utilisées par les registres régionaux pour mettre en œuvre les directives élaborées par l’IANA et indiquait que les règles restaient sujettes à révision.RFC 2050, page de titre, résumé et introduction, pages 1–2

La note de l’IESG était délibérément plus étroite qu’une approbation. En approuvant le document en tant que Bonne Pratique Actuelle, l’IESG a déclaré qu’il estimait que la politique représentait fidèlement la pratique actuelle des registres. Il a expressément refusé d’approuver ou de recommander la politique et a prévu un réexamen à la lumière des discussions ultérieures du groupe de travail. L’approbation de l’exactitude descriptive, la rédaction du texte, l’élaboration des directives des registres, la mise en œuvre par les registres et les conseils d’un groupe de travail étaient des rôles institutionnels distincts.

La RFC présentait la conservation, la routabilité et l’enregistrement comme trois objectifs. Elle reconnaissait également les conflits entre ces objectifs et avec les intérêts des utilisateurs finaux et des fournisseurs. La conservation favorisait une adéquation étroite entre l’offre et le besoin démontré. La routabilité favorisait une distribution hiérarchique sensible à la topologie. L’enregistrement favorisait des relevés précis des assignations. Une attribution optimisée pour un objectif pouvait donner de mauvais résultats par rapport à un autre: une petite allocation directe pouvait conserver le volume d’adresses mais ajouter une route; un bloc fournisseur pouvait bien s’agréger mais imposer une renumérotation; une vérification approfondie pouvait améliorer les enregistrements mais augmenter le coût des transactions.

Cette reconnaissance est la contre-preuve interne la plus solide contre un récit simpliste de bureaucratie arbitraire. Les auteurs reconnaissaient un problème technique à objectifs multiples et appelaient à un jugement prudent. Les documents justifient de prendre ce problème au sérieux. Ils ne transforment pas chaque seuil ou remède institutionnel en une conséquence nécessaire de l’en-tête.

La meilleure défense technique survit à l’audit

Un jugement équitable commence par le danger d’une surallocation irréversible. Une fois que les adresses étaient intégrées dans les configurations des routeurs, le DNS, les règles d’accès, les paramètres des applications, les systèmes des clients et la documentation, la reprise devenait coûteuse. On ne pouvait pas supposer qu’une grande attribution optimiste serait restituée proprement après l’échec des prévisions. Des allocations initiales plus petites limitaient cette exposition.

Le démarrage progressif répondait à l’asymétrie d’information. Un nouveau fournisseur connaissait mieux son plan d’affaires qu’un registre, mais aucune des parties ne pouvait observer la demande future des clients. Le processus de la RFC 2050 utilisait les besoins immédiats, les assignations en aval vérifiées et les demandes répétées pour remplacer une partie de l’incertitude des prévisions par un historique administratif observé. Cela pouvait conserver le pool et améliorer l’exactitude de l’enregistrement.

L’allocation sans classe corrigeait un décalage de taille sévère. Le choix entre 254 et 65 534 identifiants ordinaires était mal adapté aux réseaux de taille moyenne. Les préfixes contigus pouvaient se rapprocher davantage du besoin qu’une classe B native, tout en évitant une collection arbitraire de classes C non apparentées.

L’agrégation concernait une ressource partagée distincte. Les observations de routes de janvier et décembre 1992, malgré la prévision non réconciliée à deux ans de la RFC, montraient une croissance rapide dans une table concrète provenant de MERIT. Les agrégats des fournisseurs pouvaient réduire le nombre de destinations transportées par les routeurs sans défaut. Le gain dépendait de la topologie, des logiciels et de la coopération, mais il était techniquement substantiel.

La hiérarchie des fournisseurs découlait de cette logique d’agrégation. Si un client utilisait des adresses tirées du bloc de son fournisseur, le reste de l’Internet pouvait souvent s’appuyer sur l’agrégat du четыреnisseur. L’espace portable réduisait la dépendance envers un seul четыреnisseur, mais pouvait nécessiter une route globale distincte. Le réseau au sens large, et pas seulement le client et le registre, supportait l’état associé à cette route.

La documentation servait également à plus que la conservation. Les enregistrements d’assignation facilitaient la contactabilité, le DNS inverse, l’évitement des attributions en double et la vérification de l’utilisation en aval. Un demandeur sollicitant une capacité supplémentaire possédait des informations que le registre n’avait pas. Un certain examen était donc rationnel, même si chaque détail procédural pouvait être contesté.

Le pouvoir d’exception pouvait empêcher une règle numérique d’aller à l’encontre de son objectif technique. Le multihébergement, une topologie inhabituelle, des limitations d’équipement ou un besoin direct important pouvaient rendre un bloc par défaut inadapté. Un traitement au cas par cas permettait au registre de prendre en compte des circonstances qu’un simple pourcentage d’hôtes ne pouvait pas saisir.

Ces considérations établissent des arguments techniques sérieux en faveur de la conservation, de l’agrégation, de l’enregistrement, du démarrage progressif et d’un jugement prudent. Un système uniforme de grandes attributions inconditionnelles aurait pu consommer plus rapidement les unités par classes devenues rares. Un système uniforme de petites attributions routées indépendamment aurait pu étendre les tables sans défaut. Un système sans règles aurait rendu plus difficiles les attributions en double et l’évaluation comparable des besoins.

Cette défense n’établit pas l’unicité institutionnelle. Elle ne montre pas que l’horizon de 24 mois était l’horizon de prévision optimal, que la période de réapprovisionnement des FAI de la RFC 2050 minimisait le coût combiné du registre et du demandeur, qu’un registre régional unique était la seule structure viable, ou que l’appel hiérarchique était supérieur à un examen partiellement indépendant. Les preuves techniques soutiennent les objectifs et certains mécanismes. Des données sur les demandeurs, le routage, le personnel et les résultats seraient nécessaires pour classer les conceptions complètes.

Une comparaison limitée à 1996 situe l’autorité, pas les résultats

Un contrefactuel utile peut être fixé en novembre 1996, lorsque la RFC 2050 a été publiée. Maintenons constants les champs IPv4 de 32 bits, les vestiges installés capables de sans-classe et par classes de l’époque, les spécifications BGP-4 alors disponibles, les ressources limitées des routeurs, une demande incertaine, une renumérotation coûteuse et l’absence de conversion universelle immédiate à IPv6. Ne supposons pas un déploiement universel de BGP-4, du NAT ou des adresses privées, car les spécifications citées ne mesurent pas l’adoption.

Commençons par la base documentée: allocation orientée fournisseur, démarrage progressif pour les nouveaux FAI, capacité supplémentaire destinée à couvrir environ trois mois d’assignations, tests d’utilisation pour les entreprises finales, exceptions au cas par cas, autorité d’audit du registre et appel auprès du registre parent.

Faisons maintenant varier analytiquement trois paramètres institutionnels.

La première variation modifie l’intervalle de réapprovisionnement. Un FAI pourrait recevoir de quoi couvrir six mois plutôt qu’environ trois mois. Il ne s’agit pas d’une proposition historique documentée. Elle n’est administrativement plausible que dans l’hypothèse où le registre parent pourrait dimensionner un bloc contigu plus grand sans modifier les formats de paquets et que les prévisions des fournisseurs seraient suffisamment crédibles. L’effet probable sur l’autorité est une réduction du nombre de transactions avec le registre et une moindre dépendance à un réapprovisionnement rapide. Le risque probable pour la conservation est une capacité inutilisée plus importante lorsque la croissance ne se matérialise pas. Sans historiques de demandes, erreurs de prévision et données d’assignation, aucune de ces amplitudes ne peut être estimée.

La deuxième variation conserve le démarrage progressif sur trois mois mais publie à l’avance des fourchettes d’allocation et un calendrier type de preuves. Celle-ci aussi est construite par l’analyste. Elle suppose que les registres disposaient du personnel et des systèmes d’enregistrement nécessaires pour maintenir des règles publiques tout en protégeant les informations sensibles des clients. Elle pourrait réduire l’incertitude quant à la documentation et faciliter la comparaison de cas similaires, mais elle pourrait inciter à une présentation stratégique autour des seuils publiés et réduire la flexibilité pour les réseaux atypiques.

La troisième variation conserve la hiérarchie technique mais modifie l’examen. Les décisions initiales d’allocation et d’audit restent du ressort du registre; un comité non responsable de la décision初始 examine les exceptions écrites et les invalidations. Aucune source directe ne montre qu’un tel comité ait été proposé en 1996. La variation n’est administrativement concevable que si le système de registres pouvait nommer des examinateurs, partager des preuves confidentielles sous des garanties et financer une procédure supplémentaire. Elle déplace une partie de l’autorité d’examen sans ajouter de bits d’adresse ni modifier l’agrégation des routes.

Une variation plus large d’allocation directe peut également être décrite, mais ses hypothèses sont plus lourdes. Les petites organisations mono-hébergées pourraient recevoir des blocs régionaux directs et les conserver en changeant de fournisseur, sous réserve d’un préfixe minimal convenu accepté mondialement. Ce minimum, l’accord sur l’acceptation des routes et la capacité administrative sont tous des paramètres analytiques, et non des règles historiques retrouvées. Cette conception pourrait réduire la renumérotation des clients mais augmenter les routes visibles indépendamment. Le dossier cité ne prouve pas que les fournisseurs de transit auraient accepté ces routes ou que les routeurs de l’époque auraient pu absorber la table qui en aurait résulté.

La comparaison révèle où se situent les coûts et le pouvoir discrétionnaire. Un réapprovisionnement court fait peser plus de risques de transaction et de calendrier sur le FAI tout en limitant l’exposition du pool à l’échec des prévisions. Des attributions initiales plus grandes inversent une partie de cette incidence. Des fourchettes publiées échangent le pouvoir discrétionnaire contre la visibilité des règles. Un examinateur distinct déplace une partie du pouvoir correctif hors de la chaîne de décision initiale. Une portabilité plus large transfère la continuité vers le client et le coût de l’état de routage vers le réseau au sens large.

Elle ne peut pas montrer quelle variation était réalisable à grande échelle, combien d’adresses chacune consommerait, combien de routes chacune générerait, ou laquelle améliorerait le bien-être. Un calibrage nécessiterait les demandes des demandeurs, les montants accordés et refusés, les délais de traitement, les erreurs de prévision, les politiques de routage des fournisseurs, la capacité des routeurs, les coûts de personnel, les résultats des renumérotations, les dossiers d’audit et des observations comparables de l’utilisation. Ces éléments sont absents.

La conclusion fondée sur les preuves est donc plus étroite: la RFC 2050 n’a pas elle-même démontré l’unicité institutionnelle de sa conception. Elle documentait la pratique des registres de l’époque, énonçait un jugement technologique contemporain et décrivait des règles destinées à concilier des objectifs concurrents. Les variations analytiques identifient des décisions intégrées dans ces règles. Elles ne prouvent pas une performance supérieure.

Quatre conclusions, avec différents niveaux de confiance

Le fait architectural est le plus solide. La RFC 791 a fixé chaque champ source et destination IPv4 à 32 bits. Le résultat était 2^{32} valeurs nominales par champ, pas un espace de noms illimité et pas 4 294 967 296 hôtes publics attribuables.

Les conséquences liées aux classes et au routage sont également bien étayées. Les écarts importants entre les capacités d’hôtes ordinaires de la classe C et de la classe B rendaient les attributions de taille moyenne inefficaces. Plusieurs classes C pouvaient conserver un numéro de réseau de classe B tout en ajoutant des routes. Le tableau MERIT de la RFC 1519 documentait 4 526 routes annoncées en janvier 1992 et 8 561 en décembre 1992. Sa projection d’environ 30 000 à deux ans ne peut pas être reproduite à partir de la formule de doublement indiquée, mais la préoccupation sous-jacente concernant la croissance des routes et la granularité par classes ne dépendait pas uniquement de cette erreur arithmétique.

Les choix administratifs sont identifiables. La RFC d’information de Gerich recommandait des prévisions sur 24 mois, des seuils, des divisions géographiques, des audits et des exceptions au cas par cas. Les auteurs du CIDR ont lié l’allocation à la topologie des fournisseurs et à l’agrégation sans classe. Hubbard, Kosters, Conrad, Karrenberg et Postel ont documenté le démarrage progressif, la hiérarchie, les tests d’utilisation basés sur les hôtes connectés, l’autorité d’audit, l’invalidation, la restitution et l’appel hiérarchique du BCP 12. L’IANA, les registres régionaux et locaux, les fournisseurs et les réseaux de transit occupaient différents rôles de mise en œuvre. L’IESG a accepté la RFC 2050 comme une représentation fidèle de la pratique actuelle, tout en refusant d’approuver la politique.

Les résultats complets restent non résolus. Les registres d’allocation ne contiennent pas le dénominateur des demandes. Les sources citées ne révèlent pas tous les refus, réductions, retraits, conseils informels, retards, régularisations d’audit, restitutions, exceptions ou résultats d’appel. Les données ultérieures des registres contiennent des dates héritées et reconstituées. Aucun ensemble de données de l’époque cité ne mesure le déploiement universel de BGP-4, l’occupation complète des adresses, le fardeau comparable des demandeurs ou la contribution causale d’un seuil unique à la conservation.

Le titre peut supporter ces distinctions. Le champ fini était technique. L’allocation par classes et l’état des routeurs ont créé une réelle pression technique. Le régime de rationnement était politique au sens restreint, fondé sur les preuves, que des institutions identifiables ont choisi les horizons de prévision, les niveaux d’allocation, les hiérarchies, les tests de preuve, l’autorité d’exception et les recours dans le cadre de contraintes qui n’imposaient pas une constitution administrative complète et unique.

La nécessité technique justifiait l’action collective. Elle ne déterminait pas à elle seule qui définirait le besoin, détiendrait des preuves confidentielles, accorderait des exceptions, imposerait des conséquences ou déciderait de l’appel final.