Résumé

  • La RFC 1220 interdisait l’échange de trafic LAN tant que le Bridge Network Control Protocol n’avait pas ouvert la connexion. Cette ouverture attestait un état de protocole, pas la livraison d’une trame.
  • Le résultat dépendait encore d’un MRU suffisant, de l’ordre sur les liaisons parallèles, des types MAC acceptés, du sens de la compression, des identifiants LAN, du domaine d’arbre couvrant et du traitement du FCS.
  • Le CRC PPP et le FCS LAN répondaient à deux questions différentes. Une trame valide sur la liaison série pouvait ne pas préserver la preuve d’intégrité de la trame LAN d’origine.

L’autorisation de commencer n’était pas le résultat

La RFC 1220, Point-to-Point Protocol Extensions for Bridging, date d’avril 1991 et a été éditée par F. Baker. Le catalogue du RFC Editor et la fiche du Datatracker la classent Proposed Standard dans le flux IETF et indiquent qu’elle a été rendue obsolète par la RFC 1638. Ce sont des faits documentaires, non la preuve d’une installation.

Le projet cherchait à relier des ponts distants par une ou plusieurs lignes série tout en transportant des trames de LAN. Il reprenait la discipline PPP de la RFC 1171 et supposait que les deux équipements avaient déjà accepté de l’utiliser. La volonté de faire du pontage figurait parmi les prémisses du modèle ; aucune configuration réelle n’était fournie.

BNCP organisait ensuite la progression. Il attendait que LCP atteigne la phase de négociation des protocoles réseau, puis configurait les ponts. Les trames LAN ne pouvaient circuler qu’après son passage à l’état Open. Cette règle établissait une dépendance saine : le trafic ne devait pas précéder le contrôle chargé de l’encadrer.

Mais le mot « ouvert » ne disait ni quelle trame avait été transmise, ni quel port l’avait relayée, ni si le LAN distant l’avait émise, ni si son destinataire avait répondu. L’état de la machine protocolaire était une pièce de preuve, pas le récit complet du trajet.

Une absence de rejet restait une convention locale au protocole

Pour le pontage transparent, le texte considérait qu’un voisin acceptait ce service lorsqu’il recevait les BPDU IEEE 802.1 sans renvoyer de Protocol-Reject PPP. Le silence prenait donc un sens défini dans cette situation précise.

Il ne devenait pas pour autant une autorisation générale. Il n’identifiait aucun administrateur, ne démontrait pas une politique commune et ne prouvait ni l’élection de la bonne racine ni l’état Forwarding d’un port. Un exploitant pouvait même vouloir séparer deux domaines d’arbre couvrant. Les deux extrémités devaient alors être configurées pour ne pas échanger les BPDU, et un pont ainsi configuré devait jeter silencieusement le BPDU reçu par erreur.

Un observateur extérieur pouvait donc voir le même silence après une acceptation, un filtrage voulu ou un défaut à sens unique. La RFC recommandait fortement la détection de boucle par nombre magique et la surveillance de qualité, justement parce que le trafic normal de l’arbre couvrant était surtout unidirectionnel. Ne rien entendre en retour ne certifiait pas le chemin inverse.

Les options exprimaient des capacités incomplètes

BNCP négociait les types MAC, la compression des petits paquets, l’identification des LAN et certains numéros d’anneau et de pont. Une annonce de type MAC disait ce que le récepteur se déclarait prêt à traiter. Les types omis après une annonce devaient être jetés. Sans annonce, le pair pouvait supposer un support général, mais le récepteur continuait à jeter ce qu’il ne comprenait pas.

Le cas du Configure-Reject était plus révélateur encore : le refus de l’annonce pouvait signifier que l’émetteur enverrait tout de même le type de trafic que son pair venait de dire qu’il abandonnerait. La négociation rendait alors le désaccord visible sans le transformer en garde-fou contre la perte.

La compression « tinygram » n’était pas nécessairement symétrique. Une extrémité pouvait décompresser et l’autre non ; en l’absence de négociation, aucune compression n’était permise. Il fallait donc enregistrer chaque direction au lieu d’étiqueter toute la liaison « compressée ».

L’identifiant LAN était lui-même consultatif et désactivé par défaut. Activé, il annonçait que des LAN étiquetés pouvaient se trouver au-delà du pair et que celui-ci savait les desservir. Désactivé, il annonçait leur abandon. Le champ bornait une communauté de trafic, sans prouver que cette communauté correspondait à une politique d’accès humaine ou que le bon port de sortie l’appliquait.

La taille, l’ordre et les deux sommes de contrôle restaient séparés

Le MRU négocié devait accueillir les types MAC pris en charge, car le format ne prévoyait ni fragmentation ni réassemblage. Même une trame Ethernet pouvait dépasser le MRU PPP par défaut de 1 500 octets. BNCP pouvait donc être Open alors qu’une trame LAN parfaitement légitime ne tenait pas dans la liaison configurée.

Avec plusieurs lignes parallèles, l’émetteur devait savoir si le protocole ponté exigeait l’ordre original. Faute de certitude, il devait conserver cet ordre. Répartir les paquets pour gagner du débit pouvait autrement modifier un comportement supposé naturel sur un LAN unique.

Enfin, le CRC de la trame PPP était explicitement distinct du FCS LAN incorporé. Le premier protégeait le saut point à point. Le second représentait le contrôle calculé à l’origine sur la trame LAN. En son absence, un pont pouvait en faire calculer un nouveau lors de l’émission. Recevoir un PPP correct, préserver le FCS initial et livrer la trame étaient donc trois assertions différentes.

Un format ne constituait pas une observation

Les drapeaux de la RFC décrivaient la présence d’un FCS, d’un identifiant LAN, d’une compression de zéros et d’un bourrage de ligne. Le type MAC guidait l’interprétation des octets suivants. Ces éléments pouvaient prouver ce que la trame prétendait contenir, non la décision de la base de transfert, l’état du port d’arbre couvrant ou l’existence du destinataire.

Le paquet de sources ne contient ni configuration d’opérateur, ni capture de négociation, ni table MAC, ni trace de trafic, ni résultat d’application. La section sécurité de la RFC 1220 indique que ces questions ne sont pas traitées. Aucune authentification, autorité, confidentialité ou réussite opérationnelle ne peut donc être déduite du seul document.

La portée exacte de BNCP Open demeure utile : le protocole permet désormais de commencer. Elle devient trompeuse seulement quand on la rebaptise « LAN étendu opérationnel ».

Sources