Résumé

  • Le RFC 2050 faisait de la conservation, de la routabilité et de l’enregistrement trois objectifs distincts, parfois contradictoires ; le registre prouvait une attribution et une responsabilité, jamais une route mondiale.
  • Ses seuils et procédures décrivaient la pratique de 1996. Devenu Historic et remplacé par le RFC 7020, il ne peut servir de politique actuelle.

Imaginez trois dossiers posés sur la même table. Le premier compte une réserve finie d’adresses. Le deuxième cherche à réduire le nombre de routes que les opérateurs doivent porter. Le troisième exige de savoir qui utilise chaque bloc et qui appeler en cas d’incident. Le RFC 2050 disait que ces dossiers appartenaient au même système, mais pas qu’ils produisaient le même résultat.

La conservation voulait distribuer selon le besoin opérationnel et empêcher le stockage spéculatif. La routabilité poussait vers une hiérarchie compatible avec l’agrégation CIDR. L’enregistrement devait préserver l’unicité et fournir des informations de dépannage. Dès l’introduction, le texte avertissait que conservation et routabilité entraient souvent en conflit, et que les trois objectifs pouvaient heurter l’intérêt d’un fournisseur ou d’un utilisateur.

Cette tension explique une phrase qui paraît presque paradoxale dans des « lignes directrices d’allocation » : ni l’allocation ni l’assignation d’une adresse IPv4 ne garantissaient sa routabilité. Le préfixe pouvait être unique, la décision documentée et le contact public ; un opérateur de transit pouvait encore refuser l’annonce.

Le RFC distinguait soigneusement les actes. Le registre régional allouait un bloc à un fournisseur. Celui-ci assignait ensuite une partie à une entreprise finale, sans droit automatique de sous-délégation. Une inscription attestait l’acte enregistré. Elle ne configurait aucun routeur et n’engageait aucun pair.

Le dossier d’enregistrement n’était pas décoratif. Les informations de réassignation devaient être transmises rapidement pour identifier l’utilisateur et le contact opérationnel ou de sécurité, vérifier qu’un fournisseur avait largement utilisé son allocation avant d’en obtenir une autre, et alimenter les études d’allocation. Le texte liait même une nouvelle allocation à la transmission d’environ 80 % des informations de réassignation.

Les pièces examinées pouvaient couvrir sous-réseaux, masques, hôtes, topologie, protocoles, limites de routage, historique des blocs, calendrier de déploiement et croissance. Les taux de 25 % immédiatement et 50 % à un an servaient de lignes directrices. Cette précision renforçait la décision administrative ; elle ne prouvait ni la configuration en production ni la livraison d’un paquet.

Pour limiter la table mondiale, le RFC 1518 avait établi la logique de l’allocation hiérarchique. RFC 2050 conseillait donc à la plupart des fournisseurs de demander l’espace à leur amont, de conserver les blocs CIDR intacts et de rendre puis renuméroter les adresses quand le contrat d’accès prenait fin. La scalabilité gagnait ; le client assumait une dépendance et un coût de sortie.

L’espace obtenu directement auprès d’un registre restait possible pour certains réseaux multihébergés ou reliés à un grand point d’échange. Mais le texte répétait que cet espace indépendant du fournisseur était le moins susceptible d’être routable. L’accord d’un FAI reconnu pour injecter un préfixe long ne liait toujours pas les autres réseaux.

Les opérateurs de transit pouvaient filtrer les routes non agrégées ou fixer une taille minimale de préfixe pour éviter la surcharge. Voilà l’acteur absent du tampon administratif : chaque réseau contrôlait son importation. Un registre pouvait améliorer la probabilité d’agrégation, pas ordonner une propagation universelle.

Il faut aussi refuser la déduction inverse. Voir une route chez un collecteur ne démontre pas sa présence partout. Cela ne prouve ni l’autorisation de l’origine, ni l’usage effectif, ni la réponse d’un service. L’absence chez un observateur ne démontre pas davantage l’inactivité interne du bloc.

Le document contenait des règles plus dures : allocation progressive, justification des usages, audit, validité conditionnelle tant que les critères restaient remplis, possible invalidation, approbation des transferts et appel jusqu’à l’IANA. Ce sont des traces d’un accord institutionnel daté. Elles ne permettent pas de trancher aujourd’hui un droit, un contrat ou une politique régionale.

La fiche RFC Editor et le Datatracker classent désormais RFC 2050 Historic ; la recherche d’errata complète le dossier documentaire. Le RFC 7020 l’a remplacé en 2013 parce que le système avait profondément changé et que ses procédures avaient été supplantées.

RFC 7020 conserva toutefois la séparation fondamentale. Il parla de gestion du stock, d’allocation hiérarchique et d’exactitude du registre, puis plaça explicitement l’annonce réelle et sa manière de circuler hors du champ du système des registres. Le successeur modernisait le cadre sans attribuer aux registres le contrôle des routes.

La note IESG du RFC 2050 est un autre garde-fou. Le classement BCP 12 signifiait que l’IESG croyait le texte fidèle à la pratique courante des registres. La note refusait expressément d’endosser ou de recommander la politique et annonçait un réexamen en décembre 1997. Le corpus conservé ne permet pas d’inventer le résultat de ce réexamen.

Le prédécesseur RFC 1466 documentait un autre moment de l’allocation. Le RFC 2008 traitait plus directement du prêt, de la portabilité et des filtres lors d’un changement de fournisseur. Le RFC 7249 apporte un recul architectural ultérieur. Aucun ne transforme RFC 2050 en règle de 2026.

Même le registre IPv4 actuel de l’IANA doit rester à sa place : il décrit une structure d’allocation, pas la décision complète de 1996, encore moins une route ou un service actuel.

L’image du carnet d’adresses de Heng Lu aide à lire la limite : celui qui tient la liste ne conduit pas les rues. Ses textes sur les couches de réalité, la primauté du code en fonctionnement et la spécification initiale minimale servent ici de grille éditoriale contemporaine, jamais de preuve sur l’intention des auteurs.

La chaîne de preuve reste donc séquentielle : inscription datée, base d’autorité, configuration d’annonce, acceptation par les voisins, visibilité depuis des points définis, puis tests de paquets et de service. RFC 2050 mérite d’être relu précisément parce qu’il n’effaçait pas les trous entre ces étapes.

Sources