Résumé

  • Dans RFC 1474, chaque état de média appartenait à un lien PPP et à un type MAC. LocalStatus=accept engageait le traitement local ; RemoteStatus=accept ne rapportait que la conviction de l’entité locale au sujet de son pair.
  • Le défaut de RFC 1220 pouvait faire supposer qu’un pair silencieux acceptait tous les types, tout en lui permettant de jeter ceux qu’il ne comprenait pas. La négociation informait une décision d’envoi ; elle ne prouvait pas la réception.

Publié en juin 1993, RFC 1474 définissait le groupe MIB du Bridge Network Control Protocol de PPP. Son tableau ne cherchait pas à raconter le voyage complet d’une trame. Il rendait administrables une configuration, un état de protocole et des capacités par famille de média.

Cette économie imposait une discipline rare : un objet devait dire non seulement de quoi il parlait, mais d’où venait son savoir.

La colonne distante n’était pas écrite par le distant

Le tableau pppBridgeMediaTable utilisait deux index : ifIndex et pppBridgeMediaMacType. Une ligne ne valait donc ni pour tous les liens, ni pour tous les formats de trame. Elle concernait un type MAC précis sur une interface PPP précise.

Dans la colonne locale, accept signifiait que l’entité recevrait et traiterait correctement les paquets de ce type. dont-accept avertissait que les paquets reçus ne seraient pas correctement traités. Le système décrivait son propre chemin d’exécution.

La définition de pppBridgeMediaRemoteStatus changeait de registre. Elle indiquait si l’entité locale estimait que l’entité distante accepterait le même type. La donnée portait sur le pair, mais son témoin demeurait la machine locale.

Une interface qui colore les deux cellules de la même manière efface cette provenance. La capacité locale peut être reliée à une configuration et à un code local. La capacité distante est reconstruite à partir d’options reçues, de silences interprétés et d’un état de négociation.

L’absence d’annonce avait son propre sens

RFC 1220 fournissait le mécanisme. L’option MAC Type Selection permettait à un nœud d’annoncer les trafics qu’il était prêt à recevoir et à servir. Plusieurs types exigeaient plusieurs options dans le Configure-Request.

Sans annonce, le voisin pouvait supposer que tous les types étaient pris en charge. Mais le texte précisait que le destinataire jetterait ceux qu’il ne comprenait pas. Ce défaut facilitait l’interopérabilité ; il ne créait aucune fonction de décodage chez le pair.

Une annonce explicite signifiait que les types absents seraient rejetés. Même un Configure-Reject ne formait pas une clôture propre : RFC 1220 décrivait le cas où le trafic correspondant continuerait d’être transmis sur le lien alors que le récepteur avait indiqué qu’il le jetterait.

Le statut distant devait donc rester attaché à sa cause : annonce positive, omission interprétée, rejet, type MAC, lien et génération de négociation.

Une information consultative devenue plus encadrée

Le successeur de 1994, RFC 1638, recommandait fortement la négociation MAC-Support. Une annonce pouvait éviter d’envoyer des types incompatibles et économiser de la bande passante. Le document qualifiait toutefois l’option d’« advisory only ».

Pour les types MAC numérotés au-delà de 4, RFC 1638 ajoutait une règle plus ferme : aucune émission sans option du pair annonçant sa volonté de recevoir. Cette évolution resserrait le comportement applicable aux extensions. Elle ne transformait toujours pas une annonce en trace de trame livrée.

Le compromis historique devient visible : préserver les anciens pairs, limiter le trafic inutile, puis protéger de nouveaux codes. Chaque étape améliore la règle de décision locale. Aucune n’abolit l’écart entre inférence et observation.

Savoir lire un format n’indiquait pas le port de sortie

Accepter un type de média ne donnait pas encore la route d’une adresse particulière. RFC 1493 gérait cette question dans une base de transfert distincte : adresses MAC unicast, ports appris ou configurés, informations de transfert et de filtrage.

RFC 1474 demandait : ce pont sait-il traiter cette famille de trames sur ce lien ? RFC 1493 demandait : comment propager une trame destinée à cette adresse ? La seconde réponse elle-même ne prouvait pas que l’hôte final l’avait reçue.

Une chaîne vérifiable conserverait la politique locale, la génération appliquée au redémarrage, l’échange BNCP, la source de la conviction distante, la trame émise, son traitement par le pair, la décision de transfert et le reçu final.

RFC 1661 séparait encore l’état du trafic : PPP ne transportait les paquets d’un protocole qu’après l’ouverture de son NCP. Opened était un seuil indispensable, pas l’observation d’une trame.

Une conviction doit conserver son auteur

RFC 1474 isolait la configuration modifiable et signalait les risques liés au contrôle PPP. Des vues MIB protégées pouvaient restreindre les lectures et les écritures. Elles protégeaient l’accès à l’affirmation ; elles n’élargissaient pas ce que celle-ci démontrait.

Une automatisation moderne devrait accompagner tout « support distant » de son interface, type MAC, génération, état NCP, option reçue ou règle par défaut, réponse du pair et heure de calcul. Sans ces éléments, « mon modèle du pair dit oui » devient silencieusement « le pair a reçu ».

Le fonctionnement distribué a besoin d’inférences. La faute commence lorsque leur origine disparaît alors que leur apparence d’autorité subsiste.

RFC 1474 avait inscrit cette origine dans la définition même de l’objet.

Sources