Résumé

  • Dans un domaine classful, apprendre un composant d’un ancien réseau de classe A pouvait détourner les autres composants de la route par défaut.
  • L’allocation d’un nouveau stock imposait donc une compatibilité de bout en bout : registre, fournisseur, réseau client, pair, agrégat et traitement des trous.
  • Le RFC 2036 décrit des conditions et des risques prévus ; il ne mesure ni leur fréquence ni le succès d’un opérateur nommé.

Une petite route changeait la signification du grand bloc

Le point de départ n’était pas une panne. Le RFC 2036 commentait une recommandation possible : permettre à l’IANA, par l’intermédiaire des registres délégués, d’allouer en préfixes sans classe les portions encore libres de l’espace historiquement appelé classe A. Jusqu’alors, les allocations CIDR prudentes formaient souvent des superblocs de réseaux de classe C. Les masques nouveaux restaient ainsi compatibles avec de vieux réflexes.

Cet arrangement laissait survivre des fournisseurs qui n’importaient qu’une route par défaut et utilisaient encore une logique classful. Leurs pairs pouvaient faire l’agrégation mandataire de blocs contigus. Mais une tranche découpée dans un parent de classe A n’avait plus cette propriété.

Si le routeur connaît le défaut et un sous-réseau du parent, la logique classful peut transformer ce sous-réseau en connaissance du parent entier. Les adresses des autres tranches ne suivent plus nécessairement le défaut. La présence d’une route de secours n’est donc pas la preuve qu’elle sera consultée. Le conflit porte sur l’interprétation qui précède la sélection.

Le RFC en tire une obligation nette pour les fournisseurs : le routage sans classe devient nécessaire même en présence d’un défaut. L’agrégation par un pair ne suffit plus. L’ouverture du stock ne peut pas être séparée du logiciel qui conserve le masque.

Le défaut de sous-réseau devait pointer dans l’autre sens

Le client non transitif rencontrait un paradoxe opérationnel. Avec d’anciens blocs alignés sur les classes, un défaut de sous-réseau explicite ne devait pas être dirigé vers le fournisseur, afin d’éviter une boucle à la frontière. Avec un composant classless de classe A, le RFC 2036 exigeait l’inverse pour le cas classful toléré : le défaut propre au parent devait suivre le défaut général vers le fournisseur.

Ce retournement n’éliminait pas le risque. Des routes de sous-réseau pouvaient fuir vers le fournisseur, qui devait alors produire l’agrégat correct. S’il annonçait tout le bloc attribué et renvoyait au client le trafic destiné à une partie non déployée, le paquet pouvait tourner entre les deux domaines. S’il ne routait que les parties effectivement annoncées, le même paquet pouvait traverser une succession de défauts avant d’être jeté au premier point sans défaut.

Le document recommande donc des routes puits pour toutes les parties non déployées. L’agrégat et le puits forment une paire de responsabilités : le premier réduit l’état publié, le second limite la promesse du résumé. Une configuration affichée ne prouve toutefois ni son installation dans la FIB ni le sort du paquet.

Une nouvelle liaison pouvait invalider l’exception

Un domaine isolé pouvait conserver son protocole classful sans conséquence externe. Un domaine raccordé une seule fois pouvait encore fonctionner sous une exception soigneusement bornée. Le multi-homing supprimait cette marge : deux fournisseurs pouvaient présenter des composants différents du même parent et l’IGP interne devait préserver leurs longueurs.

Le pair-à-pair rendait l’exigence transitive. Le RFC imagine deux réseaux terminaux classless reliés par un troisième domaine classful. Celui-ci reçoit une tranche, la promeut au parent complet et l’annonce à l’autre terminal. Le défaut fourni par son opérateur est alors supplanté ; le trafic traverse le domaine intermédiaire, atteint le premier terminal et y est rejeté faute de destination locale.

La topologie est donc une partie du contrat de compatibilité. Dire qu’un client est « compatible CIDR » ne suffit pas si un pair adjacent efface le masque. Une liaison ajoutée après l’allocation peut transformer une exception jadis sûre en détour permanent.

Le registre devenait un levier de déploiement

Le RFC propose d’allouer d’abord aux environnements déjà sans classe, ou aux domaines isolés ou mono-raccordés capables de respecter le défaut requis. Il demande aux équipements de rendre explicite le mode classful ou classless et le comportement du défaut de sous-réseau : suivre le défaut ou finir dans un puits. Il prévoit aussi une configuration d’hôte fondée sur un préfixe local, non sur la seule décomposition classe/sous-réseau/hôte.

Un mois plus tard, le RFC 2050 énonçait que les attributions supposaient des masques de longueur variable et des technologies sans classe ; une demande fondée sur un usage classful ne devait pas être retenue. Ce texte est un indice de convergence administrative, pas un registre de migration des réseaux.

Le groupe ALE explique la pression. Sa charte couvrait la durée de vie d’IPv4, l’utilisation, les politiques d’allocation, le nombre de routes, la récupération et le renumérotage. Le RFC 2036 rapporte son inquiétude concernant la consommation de l’espace de classe C et la réserve encore importante dans la moitié haute de la classe A. Il ne publie ni série brute ni taux de réussite.

Le statut Historic ferme la question normative, pas la question probatoire

Publié comme Informational, le RFC 2036 est aujourd’hui Historic et ne possède aucun erratum répertorié. En 2006, le RFC 4632 a justifié ce changement par le déploiement complet de CIDR et par plus de six années d’expérience d’allocations classless dans l’ancien espace de classe A. Ce jugement ultérieur indique que le problème n’était plus une recommandation active. Il ne révèle pas qui a échoué, combien de fois, avec quel produit, ni si les mesures du RFC 2036 ont causé l’issue.

Le RFC 4632 conserve une règle révélatrice : l’origine d’un agrégat doit jeter les paquets qui correspondent au résumé mais à aucune route plus spécifique. C’est la forme architecturale durable du trou que le RFC 2036 voulait borner. Le registre IANA actuel ne montre plus la réserve libre décrite en 1996 ; les documents ultérieurs sur les derniers /8 et l’après-épuisement ferment le contexte d’inventaire, sans créer rétrospectivement un journal d’incidents.

Six reçus devraient rester distincts : l’allocation exacte, la politique et le défaut du fournisseur, l’IGP et le défaut du client, le déclencheur de l’agrégat et ses puits, la conservation des masques chez chaque pair, puis le prochain saut réellement observé. Le registre définit un nombre ; le réseau doit encore exécuter sa frontière.

La primauté du code en fonctionnement proposée par Heng Lu aide à lire cette histoire sans rabaisser la coordination. L’enregistrement est réel au niveau administratif. La route et le paquet sont réels à d’autres niveaux. L’erreur consiste à demander au premier de servir de preuve pour les deux autres.

Sources