Résumé
- En 1992, pouvait-on rapprocher l’enregistrement des réseaux régionaux sans fragmenter le système commun d’adresses ? Le RFC 1366 proposait huit blocs de classe C, mais conservait une seule racine.
- L’Internet Registry conservait les classes A et B et devait rester le registre par défaut ; seules des plages de classe C étaient proposées pour une délégation régionale.
- Le soutien de plusieurs groupes techniques ne constituait ni un vote mondial ni un transfert de propriété des adresses aux régions.
Le service devait voyager, pas la racine
Pour un opérateur qui raccordait un réseau en expansion en 1992, obtenir des numéros supposait de savoir quel organisme traiterait la demande et selon quelles règles. Le RFC 1366 en a fait une question de gouvernance d’Internet : à mesure que le réseau franchissait les frontières, l’enregistrement pouvait-il se rapprocher des opérateurs et des abonnés sans fragmenter le système d’adresses ? Le texte proposait un service régional et huit blocs de classe C, tout en maintenant l’Internet Registry à la racine, comme registre par défaut et détenteur de tous les numéros A et B.
Cette limite donne sa portée au projet : le travail d’enregistrement pouvait être délégué, mais le cadre commun d’allocation restait central. Le RFC prolongeait une recommandation du Conseil des activités Internet, formulée en août 1990, en faveur de délégations encadrées avec maintien du registre principal.
Le RFC 1366 formule un motif concret : des registres situés dans différentes régions pourraient mieux répondre aux besoins locaux de langue et de coutumes. Le texte cite l’Europe, l’Amérique centrale et du Sud ainsi que le Pacifique, où la maturité des réseaux semblait justifier l’examen d’organisations régionales. Il ne supprimait toutefois pas le niveau central. L’Internet Registry demeurait la racine du système, le service de repli et le point de contact pour les réseaux que le registre régional ne pourrait pas aider.
Une délégation très circonscrite
La proposition réservait à l’Internet Registry tous les numéros de classe A et B, jugés limités. Son tableau de juin 1992 recensait 49 réseaux A sur 126 déjà attribués (38 %), 7 354 réseaux B sur 16 383 (45 %) et 44 014 réseaux C sur 2 097 151 (2 %). Le choix de déléguer ne portait donc pas sur toutes les adresses ni sur les parties alors les plus sollicitées. Ces classes relèvent du plan classful de l’époque, pas des préfixes CIDR actuels.
Le RFC découpait la classe C en huit blocs de même taille, environ 131 072 adresses chacun. Certains étaient associés à l’Europe, à l’Amérique du Nord, au Pacifique ou à l’Amérique centrale et du Sud ; d’autres restaient réservés aux cas « autres » ou multi-régionaux. Cette carte visait l’organisation de l’allocation et l’agrégation des routes. Elle n’affirmait pas qu’une zone géographique détenait les ressources affectées à son bloc.
Le candidat régional devait être reconnu par les autorités de réseau locales, déjà établi au-delà de la fonction d’enregistrement, capable d’assurer un service stable et disposé à suivre les règles de l’IANA et de l’Internet Registry. Il devait également coordonner les critères de sous-attribution avec ce dernier. Le RFC envisageait un seul registre régional par zone à ce niveau. La délégation était ainsi une mission encadrée, pas une souveraineté nouvelle.
Le calendrier n’était pas un bilan
Le RFC 1366 était informatif et ne définissait pas de norme Internet. Son résumé rapporte un soutien général du Federal Engineering Task Force, du Federal Networking Council, des coprésidents de l’IEPG et de RIPE. Ces groupes identifiés ne sont pas l’ensemble des utilisateurs d’Internet et leur accord n’est pas un scrutin mondial.
Le RFC 1367, publié en parallèle, proposait d’accepter les candidatures dès le 31 octobre 1992, de réexaminer le calendrier en février 1993, puis de commencer en avril les allocations de classe C selon le plan. Il qualifiait lui-même ce calendrier de projet et invitait à le discuter. Ces échéances documentent une intention; elles ne prouvent pas, à elles seules, que chaque étape fut menée exactement à la date prévue.
La chronologie européenne précède ce plan général : RIPE avait proposé un centre de coordination en 1990, publié un plan d’activité en mai 1991, puis le RIPE NCC a commencé à fonctionner en avril 1992. Le RFC 1366 n’a donc pas fondé le premier registre régional. Il a donné un cadre d’allocation à une fonction de service déjà en construction.
Le bloc du Pacifique a une suite documentée. Selon l’histoire institutionnelle d’APNIC, une proposition de NIC régional a été acceptée lors de la réunion APCCIRN de 1993, puis un pilote s’est déroulé de septembre 1993 à juin 1994. En avril 1994, l’IANA a délégué 202/8 et 203/8 à APNIC : les mêmes plages que le tableau du RFC associait au Pacifique. Cela confirme une trajectoire ultérieure, pas l’exécution de chaque bloc ni de chaque date prévue.
Cette distinction explique la portée historique du texte : déléguer l’enregistrement pouvait réduire la distance entre les réseaux et le service qui tenait leurs dossiers, tout en conservant une racine et des règles communes. Une région pouvait organiser le service; le document ne lui attribuait pas la propriété politique des numéros.
Sources
- RFC 1174 — Politique recommandée par l’IAB pour distribuer l’attribution des identifiants Internet (1990)
- RFC 1366 — Directives de gestion de l’espace d’adressage IP (1992)
- RFC 1367 — Calendrier des directives de gestion de l’espace d’adressage IP (1992)
- RIPE NCC — The RIPE Registry
- RIPE-039 — Procedures To Set Up The RIPE NCC (1991)
- APNIC — The First 20 Years
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
