Résumé

  • RFC 3147 décrivit le chemin qui manquait : IPv4 ou IPv6 dans GRE, puis le paquet GRE comme données d’un PDU CLNP, afin d’atteindre un équipement IP au-delà d’un cœur CLNS.
  • Le N-SEL 47 suggéré sélectionnait GRE au point d’extrémité CLNS ; le Protocol Type de GRE identifiait le protocole intérieur. Ces deux reçus ne démontraient pas le résultat de la gestion.
  • La transition créait une dépendance croisée : le successeur devait emprunter son prédécesseur jusqu’à ce qu’un autre chemin, la sécurité, les tailles de paquets et l’état réel des équipements soient vérifiés.

Deux îlots orientés en sens contraire

Les réseaux de gestion SONET et SDH avaient déjà une histoire matérielle. GR-253-CORE de Bellcore et G.784 de l’UIT-T avaient imposé CLNS dans cet environnement, et les exploitants avaient constitué de grands réseaux autour de cette exigence. Lorsque des constructeurs commencèrent à gérer de nouveaux éléments par IP, le changement du terminal ne remplaça pas le transport intermédiaire.

Une première topologie plaçait un ancien élément CLNS derrière un nouveau réseau IP. GRE permettait déjà de faire passer le PDU CLNP dans IP. La topologie inverse posait une autre question : comment joindre un nouvel élément IP situé derrière le réseau CLNS encore en service ? Réutiliser la première phrase à l’envers n’était pas une architecture.

RFC 3147 plaça donc le paquet IPv4 ou IPv6 dans GRE, puis le paquet GRE entier dans la partie données d’un PDU CLNP. CLNP accomplissait le trajet dans le domaine installé. À la sortie, un point de tunnel retirait successivement CLNP et GRE avant de remettre le paquet au monde IP.

Le cœur CLNS ne devenait pas un routeur IP, et l’élément géré ne participait pas nécessairement au tunnel. La continuité existait entre deux extrémités précises. Confondre cette continuité avec un remplacement achevé aurait masqué la dépendance que le tunnel venait justement de rendre visible.

Chaque enveloppe gardait sa propre réalité

L’en-tête IP intérieur portait les coordonnées de la conversation de gestion. GRE indiquait la nature du protocole encapsulé. CLNP portait les adresses et la décision d’acheminement dans le réseau effectivement traversé. Une seule capture contenait ainsi plusieurs actes, sans que l’un certifie le suivant.

La réception du PDU CLNP prouvait une livraison au point de tunnel. Un en-tête GRE valide autorisait une interprétation des octets. La remise d’un paquet IPv6 démontrait une décapsulation. Il fallait encore prouver que l’application de gestion avait accepté la requête, que le bon équipement l’avait exécutée et que son état observable correspondait à la réponse.

Les noms appartenaient eux aussi à des plans distincts. Le NSAP désignait une extrémité CLNS ; l’adresse IP décrivait une destination IP ; l’identité opérationnelle de l’équipement pouvait venir de l’inventaire, d’un certificat ou d’un emplacement physique. Une base qui les réduisait à une seule adresse détruisait la provenance au moment où celle-ci devenait la plus utile.

Le nombre 47 ne disait pas tout

CLNS utilisait le dernier octet du NSAP, le N-selector ou N-SEL, pour distribuer les données à différents utilisateurs du Network Service. Deux constructeurs avaient besoin d’une convention commune signifiant que les données CLNP commençaient par GRE. RFC 3147 suggéra la valeur décimale 47, identique au numéro de protocole IP attribué à GRE.

Ce rapprochement simplifiait l’exploitation ; il ne fusionnait pas les registres. N-SEL 47 sélectionnait GRE. Le champ Protocol Type de GRE indiquait ensuite IPv4, IPv6 ou un autre protocole pris en charge. Classer tout trafic N-SEL 47 comme IPv4 supprimerait précisément l’étape nécessaire pour comprendre l’encapsulation.

Le caractère suggéré de la valeur devait rester visible. L’accord sur le N-SEL rendait une interopérabilité possible. La publication d’un numéro ne prouvait pas que tous les produits l’avaient adopté, qu’ils interprétaient les autres champs de la même façon ou qu’un exploitant nommé avait obtenu un service utilisable.

Le reçu minimal comportait donc NSAP source et destination, N-SEL, version et options GRE, Protocol Type, adresses internes, empreinte du paquet et instant d’observation. L’étiquette « tunnel actif » était trop pauvre.

Un petit paquet pouvait mentir sur le chemin

Chaque encapsulation ajoutait des octets. Le réseau CLNS comportait ses propres limites de taille, invisibles pour l’émetteur IP. RFC 3147 recommandait d’activer Segmentation Permitted dans CLNP. Sans cette permission, un PDU trop grand pour une liaison intérieure pouvait être abandonné, sans explication utile pour l’origine IP.

Une courte sonde passait alors qu’une configuration plus volumineuse disparaissait. Le tableau de bord concluait que l’équipement était joignable, puis attribuait l’échec à l’application. En réalité, le chemin n’était valable que pour certaines tailles et certains choix de fragmentation.

À l’entrée du tunnel, RFC 1191 imposait encore la logique de découverte du MTU IPv4. Avec DF à zéro, l’entrée pouvait fragmenter avant l’encapsulation. Avec DF à un, elle devait abandonner le paquet et envoyer un ICMP signalant la fragmentation nécessaire. Encore fallait-il que cet ICMP retrouve l’émetteur.

Une preuve de service devait conserver longueur initiale, état DF, surcoût, permission de segmentation, taille de la liaison limitante, fragments et ICMP observés. Sans cela, le trou noir dépendant de la taille ressemblait à une panne aléatoire de l’équipement.

La sécurité restait hors du tunnel

Le texte était explicite : ni CLNS ni GRE n’apportaient ici de sécurité. Si le trafic de gestion exigeait une protection, une autre méthode devait être appliquée au contenu avant son entrée dans GRE sur CLNS. L’encapsulation ne constituait ni une authentification, ni un chiffrement, ni une autorisation.

Un paquet pouvait franchir correctement les trois couches et rester une commande interdite. Le point de sortie pouvait remettre exactement les octets reçus tandis que l’application les refusait. À l’inverse, une réponse apparente ne prouvait pas l’identité de l’équipement sans mécanisme indépendant.

Les extensions GRE ultérieures et les outils contemporains peuvent compléter un déploiement. Ils ne doivent pas être prêtés rétrospectivement au document de juillet 2001. L’histoire doit nommer le contrôle réellement observé.

La dépendance donnait du poids à l’ancien réseau

Après l’installation du tunnel, les nouveaux équipements dépendaient de CLNS pour être gérés. Le réseau présenté comme ancien devenait une composante du service nouveau. Le retirer trop tôt isolait d’abord les éléments qui symbolisaient la modernisation.

Ce verrouillage n’était pas éternel. Il imposait une preuve de sortie : autre route native vérifiée pour chaque équipement, comportement connu pour plusieurs tailles, protection déplacée avec le trafic, retour arrière exercé et état des appareils confirmé après bascule. Un compteur de décapsulation ne suffisait pas.

Les pouvoirs restaient distribués. L’exploitant CLNS contrôlait les routes et le plan NSAP ; l’exploitant IP contrôlait la nouvelle accessibilité ; le constructeur contrôlait le comportement de gestion ; le responsable opérationnel assumait le risque de coupure. L’IETF pouvait normaliser la couture, non réunir ces autorités.

RFC 3147 montre ainsi une migration sans rhétorique de victoire. CLNP sur IP desservait l’ancien équipement derrière le nouveau réseau ; IP sur CLNS desservait le nouvel équipement derrière l’ancien. Les dépendances se croisaient. La spécification minimale assurait le passage, tandis que le code en fonctionnement conservait le droit de contredire le plan.

Si les enveloppes arrivaient mais que l’état de l’équipement ne changeait pas, la gestion avait échoué. Si les petits paquets passaient et les grands non, le chemin n’était pas utilisable en général. Si CLNS restait le seul retour arrière, la migration n’était pas irréversible. Le tunnel maintenait la continuité ; il ne délivrait pas le certificat de remplacement.

Sources