Résumé

  • RFC 2043 définissait deux protocoles de contrôle réseau SNA négociés séparément : 0x804B commandait le trafic SNA sur LLC 802.2 identifié par 0x004B, tandis que 0x804D commandait les NLP HPR identifiés par 0x004D.
  • L’état Opened autorisait PPP à transporter l’enveloppe correspondante. Faute d’options de configuration SNACP et de discussion de sécurité, il ne prouvait ni l’autre enveloppe, ni la récupération d’erreur, ni l’identité, l’autorisation, la livraison, le déploiement ou la réussite d’une session.

L’expression « SNA est ouvert » économise quelques mots au prix d’une information décisive : quel SNA, ouvert par quel protocole de contrôle, pour quelle forme de paquet ? RFC 2043 oblige à répondre.

Publié en octobre 1996, le texte ne raconte pas l’héritage complet de SNA et ne présente pas PPP comme une garantie universelle d’interfonctionnement. Il règle un problème beaucoup plus précis. Sur un lien point à point déjà établi, deux familles de paquets SNA doivent rester discernables et chacune doit obtenir sa propre permission de circuler.

Le lien commun n’était que le socle

RFC 1661 organisait PPP en phases. LCP établissait, configurait et testait la liaison de données. Une authentification facultative et une détermination de qualité pouvaient intervenir avant la phase des protocoles de couche réseau. À ce stade seulement, chaque protocole réseau devait être configuré par son NCP approprié.

Une conséquence souvent perdue dans les tableaux de bord en découle : LCP ouvert n’équivaut pas à un protocole réseau ouvert. RFC 1661 permettait à chaque NCP d’entrer ou de sortir de l’état Opened indépendamment. Un paquet d’un protocole pris en charge, reçu avant l’ouverture de son NCP, devait être rejeté silencieusement.

RFC 2043 conserve cette discipline et la porte à l’intérieur de SNA. Il précise qu’il existe en réalité deux NCP SNA, l’un pour SNA sur LLC 802.2, l’autre pour SNA sans LLC 802.2, et qu’ils sont négociés séparément et indépendamment. La liaison partagée crée une condition matérielle commune, pas une autorité commune sur leurs états.

Deux couples, pas quatre étiquettes interchangeables

La structure des numéros PPP révèle la fonction. Les valeurs 0***–3*** identifient les paquets de couche réseau ; les valeurs 8***–b*** identifient les NCP associés. Les quatre attributions figuraient déjà dans RFC 1700 et restent inscrites dans le registre IANA actuel.

Dans le premier couple, 0x804B désigne le contrôle de SNA sur LLC 802.2. Une fois ce NCP ouvert, 0x004B transporte exactement une PIU SNA XID ou FID2 précédée des champs LLC : DSAP, SSAP, contrôle et information. Ce n’est pas une simple décoration de trame. RFC 2043 affecte LLC(2) à la récupération d’erreurs au niveau du lien et place ce travail dans les routeurs aux deux extrémités du lien PPP.

Dans le second couple, 0x804D désigne le contrôle SNA sans ce revêtement LLC. Le paquet 0x004D contient exactement un Network Layer Packet HPR, formé d’un en-tête réseau, d’un en-tête de transport et de données.

Ouvrir 0x804B n’ouvre donc pas 0x804D. Voir 0x004D ne renseigne pas sur l’état du chemin 0x004B. Une alarme qui réduit les deux à « SNACP » supprime la dimension dont un diagnostic a besoin.

La responsabilité de récupération n’est pas la preuve de la récupération

La voie LLC a une particularité : ses routeurs terminaux doivent exécuter la récupération d’erreurs du lien. Cela permet d’identifier l’endroit où chercher des compteurs, temporisations et retransmissions. Cela ne permet pas de présumer leur succès.

Un paquet 0x004B observé établit la forme de l’enveloppe à ce point d’observation. Il n’établit ni la réception au second routeur, ni une retransmission réussie, ni l’acceptation de la PIU, ni le traitement du BIU par une demi-session SNA. Le contrôle indique une permission ; les journaux de récupération et d’application doivent fournir les verdicts ultérieurs.

RFC 2043 mentionne aussi qu’un NLP HPR pourrait, en architecture, passer par LLC sur PPP si l’implémentation incluait la tour facultative de récupération HPR. Cette possibilité ne transforme pas les deux chemins en un seul. Elle décrit un choix d’implémentation dont la présence doit elle-même être prouvée.

Une négociation sans option ne transporte pas de promesse cachée

SNACP reprend l’automate d’échange de LCP, mais n’emploie que les codes 1 à 7, de Configure-Request à Code-Reject. Le texte ajoute ensuite une contrainte radicale : il n’existe aucune option de configuration, ni pour SNA, ni pour SNA sur LLC 802.2.

La négociation peut donc ouvrir un type fixe d’enveloppe. Elle ne négocie aucune identité SNA, aucun objectif de récupération, aucun profil applicatif, aucun itinéraire, aucune propriété de sécurité et aucun résultat transactionnel. Un Configure-Ack ne peut pas confirmer une information absente du Configure-Request.

Le mot Opened appartient à cet automate étroit. Il ne doit pas être transformé en adjectif général appliqué au service.

La sécurité restait expressément hors champ

La section Security Considerations de RFC 2043 indique que les questions de sécurité ne sont pas abordées. PPP pouvait employer une authentification avant la phase réseau, mais RFC 1661 la rendait facultative par défaut. Même lorsqu’une authentification distincte existe, sa méthode, son pair et son résultat doivent être attestés par leurs propres traces.

SNACP ouvert ne prouve ni identité, ni autorisation interne à SNA, ni confidentialité, ni intégrité de bout en bout. De même, la taille maximale d’un paquet SNA — égale au champ Information PPP, dont le MRU vaut 1500 octets par défaut — décrit une capacité de contenant, non le traitement du contenu.

La postérité d’une preuve modeste

RFC 2200 classait PPP-SNACP parmi les protocoles Elective en 1997. RFC 3790 constatait ensuite son absence de dépendance à IPv4. L’IANA conserve les quatre valeurs. Ces sources documentent un statut, une structure et une identité de registre ; elles ne mesurent aucune adoption.

Il n’existe pas, dans ce dossier, de preuve d’un déploiement nommé, d’une interopérabilité testée, d’un volume de trafic ou d’un résultat métier. L’absence actuelle d’errata enregistrés décrit le registre des errata, pas la perfection du mécanisme.

La grille de Heng Lu permet de conserver cette modestie. La spécification rend vérifiable une permission commune minimale. Le code exécuté, les captures aux deux extrémités, les journaux de récupération et l’application établissent des réalités différentes. Publier une règle de compatibilité ne fait pas apparaître son adoption.

Un rapport fiable doit donc conserver quatre lignes : PPP a atteint la phase réseau ; tel SNACP a atteint Opened ; tel numéro de données a été transporté ; telle preuve indépendante décrit la suite. La liaison n’est pas le protocole, le protocole ouvert n’est pas la livraison, et la livraison n’est pas le résultat applicatif.

Sources