Résumé

  • RFC 2097 demandait au pair distant d’ajouter un ensemble précis de noms NetBIOS. Une même négociation pouvait accepter certains noms et attribuer à d’autres un motif d’échec explicite.
  • NBFCP rendait aussi visibles la classe du pair, le rythme et la priorité du multicast, ainsi que l’éventuelle obligation d’un en-tête IEEE MAC de douze octets.
  • L’état Opened et Added=0 n’étaient que des preuves locales. Ils n’établissaient ni unicité mondiale, ni identité, ni autorisation, ni connexion entre deux LAN, ni livraison complète, ni sécurité.

Une liaison d’accès distant peut être active, LCP achevé et PPP déjà entré dans la phase des protocoles réseau, tandis que le nom dont dépend une application n’existe toujours pas sur le réseau opposé. RFC 2097 a rendu cet écart observable.

Publié en janvier 1997, le PPP NetBIOS Frames Control Protocol associait 0x803f aux paquets de contrôle NBFCP et 0x003f aux datagrammes NBF. Son domaine était volontairement étroit : un système terminal pouvait joindre un pair ou le LAN auquel ce pair était raccordé. Le document excluait le raccordement de deux LAN, précisément à cause des limites des noms NetBIOS et de leurs mécanismes de défense.

Ouvrir le support ne suffisait pas à admettre les noms

PPP séparait les étapes. LCP établissait, configurait et testait la liaison ; l’authentification ou le contrôle de qualité pouvaient intervenir ; NBFCP ne devait circuler qu’une fois atteinte la phase des protocoles réseau. Les datagrammes NBF n’étaient autorisés qu’après l’état Opened de NBFCP.

Pour un système terminal, RFC 2097 imposait néanmoins la négociation de Name-Projection. Le demandeur transmettait les noms NetBIOS de seize octets que le pair devait ajouter à son réseau, en précisant pour chacun s’il s’agissait d’un nom unique ou de groupe. Le champ Length d’un octet limitait chaque option à quatorze noms ; un ensemble plus grand exigeait plusieurs options.

Il ne s’agissait donc pas d’une déclaration abstraite de compatibilité NetBIOS. Un poste pouvait porter plusieurs noms associés à des services ou rôles distincts. Le pair devait tenter de donner à chacun une présence utilisable sur son côté de la liaison.

Une admission partielle devait laisser une trace

Si le pair récepteur ne pouvait pas ajouter tous les noms, il devait renvoyer un Configure-Nak contenant la liste complète. Les noms ajoutés portaient Added=0 ; les autres recevaient un code non nul : doublon dans la table locale, table pleine, nom déjà utilisé sur le NetBIOS distant, conflit détecté, nom défini par un autre environnement ou ressources épuisées.

La liste devenait à la fois proposition et reçu. Deux noms envoyés ensemble pouvaient connaître des destins différents. Le demandeur était invité à soumettre de nouveau les noms acceptés, tout en conservant la possibilité d’arrêter NBFCP si le lot complet était indispensable à l’application. Le réseau ne décidait pas de la valeur fonctionnelle du nom manquant.

Le temps faisait lui aussi partie de la preuve. L’ajout des noms prenait souvent environ trois secondes, soit le délai de reprise par défaut de PPP. Le RFC recommandait dix secondes pendant cette opération. Une nouvelle tentative trop rapide pouvait révéler une minuterie impatiente, non l’absence du système distant.

Added=0 autorise donc une phrase précise : lors de cet échange, ce pair a déclaré avoir pu ajouter ce nom. Le résultat ne démontre pas que tous les segments, serveurs de noms ou ponts possédaient une vue cohérente. RFC 1001 reconnaissait d’ailleurs que des pannes pouvaient laisser les informations de noms dans un état incohérent.

Le rôle annoncé par le pair n’était pas une identité vérifiée

Peer-Information permettait d’indiquer une classe d’implémentation, des versions majeure et mineure et, facultativement, un nom de pair. Les classes distinguaient notamment une passerelle NetBIOS sur PPP, un serveur d’accès local uniquement, un pont NBF et un système terminal.

Cette différence changeait la surface opérationnelle : un pont n’avait pas les mêmes fonctions qu’un serveur incapable de transmettre des paquets. Pourtant l’option était seulement recommandée, et le pair fournissait lui-même sa classe et son nom. Aucun lien cryptographique ne rattachait ces octets à une machine, une organisation ou un opérateur authentifié.

La politique multicast pouvait cacher un service pourtant joignable

Certaines applications NetBIOS dépendaient du multicast ; d’autres n’en avaient pas besoin. Multicast-Filtering négociait donc une période maximale de transmission et un bit de priorité. Zéro signifiait que tous les paquets multicast devaient être transmis. Une valeur ordinaire, plafonnée à soixante secondes, limitait la fréquence. 0xFFFF exprimait une valeur inconnue ou inexistante selon le sens de l’échange. La priorité déterminait si le trafic multicast passait avant le trafic dirigé.

Ces paramètres transformaient une politique de bande passante en comportement d’application. La liaison pouvait rester ouverte et les noms être projetés, tandis qu’un logiciel tributaire d’annonces fréquentes paraissait en panne. L’accord sur une période décrivait une politique du pair ; il ne garantissait pas l’arrivée de chaque paquet.

Douze octets supplémentaires modifiaient le contrat de trame

Les paquets NBF existaient avec plusieurs en-têtes historiques : Ethernet 802.3, Token Ring 802.5, DIX Ethernet et FDDI. Certaines implémentations PPP exigeaient l’en-tête complet pour ponter le trafic, d’autres seulement les adresses IEEE, et certaines passerelles aucun champ MAC.

L’option IEEE-MAC-Address-Required matérialisait ce besoin. Par défaut, aucun en-tête MAC n’était ajouté. Une fois l’option acceptée, chaque datagramme devait commencer par douze octets d’adresses source et destination. La décision intervenant après la négociation du MRU par LCP, le récepteur devait aussi accepter des paquets NBF dépassant ce MRU de douze octets.

La valeur du MRU n’était donc pas à elle seule le contrat complet. Observer l’en-tête prouvait la forme de l’enveloppe, pas le passage effectif d’un pont ni la réception par le destinataire nommé.

Opened accordait une permission étroite, pas un certificat de résultat

Les quatre options de RFC 2097 séparaient ce que les tableaux de bord fusionnent souvent : noms admis, rôle déclaré du pair, traitement du multicast et forme de trame. Opened autorisait alors NBF sur cette liaison et selon ces termes.

Le RFC ne fournissait aucun halo de sécurité. Sa section Security Considerations précisait que la sécurité n’était pas traitée. NBFCP n’authentifiait pas une machine, n’autorisait pas un nom, ne chiffrait pas les données et n’attestait pas leur intégrité. En refusant l’usage LAN-à-LAN, le texte conservait la frontière entre projection locale et réseau routé général.

L’IANA conserve aujourd’hui les deux valeurs de protocole, les quatre options, les codes de résultat et les classes de pair. Cette continuité prouve l’identité des numéros, non leur déploiement. L’absence d’erratum enregistré n’est pas davantage une mesure d’interopérabilité.

La comparaison avec RFC 1088 précise encore la différence. RFC 1088 construisait mécaniquement un nom NetBIOS à partir d’une adresse IPv4. RFC 2097 ne dérivait aucun nom : il transportait un ensemble choisi jusqu’à un point d’admission distant et rendait une décision pour chaque entrée.

À la lumière ultérieure des principes de Lu Heng sur la spécification minimale et la primauté du code en service, NBFCP ressemble à une couche commune limitée aux engagements nécessaires à l’interopérabilité. C’est une lecture éditoriale, non l’intention prouvée de l’auteur du RFC. Le fait historique suffit : une liaison ouverte ne pouvait plus résumer l’accès lorsque chaque nom, chaque politique multicast et chaque forme de trame disposait de son propre reçu.

Sources