Résumé

  • La RFC 2153 réserve une enveloppe propriétaire commune afin que les fournisseurs ne s’attribuent pas secrètement des Codes et Types PPP en conflit.
  • L’OUI indique qui administre le sens ; Kind et Values restent privés, de sorte qu’une trame valide peut demeurer inconnue ou interdite.
  • Configure-Ack accepte un ensemble exact d’options pour une négociation ; l’activation, le trafic et le résultat du service exigent d’autres preuves.

Un accusé de réception devant une boîte fermée

Un analyseur reconnaît Code 0, vérifie Length et affiche un OUI puis un Kind. Il a correctement livré une enveloppe à un espace de noms. Il n’a pas encore ouvert la boîte : aucun fait n’établit que le pair possède le bon décodeur, connaît cette version des Values ou a reçu l’autorisation de l’exécuter.

C’est la frontière de la RFC 2153. Ce document informatif de 1997 voulait empêcher les fournisseurs de choisir en secret des valeurs ordinaires de Code LCP/NCP ou de Type d’option. L’enveloppe commune réduit les collisions sans normaliser l’algorithme propriétaire.

Le paquet Vendor Specific utilise Code 0. Son Identifier change à chaque nouveau paquet ; il transporte Magic-Number, OUI, Kind et éventuellement Values. Il peut arriver avant même l’état LCP Opened. Sa réception déclenche RXR ou RUC, mais la réponse reste définie par le fournisseur. Un Code-Reject conduit à RXJ+, rejet permis. La machine d’états a donc vu un paquet ; elle n’atteste pas son sens.

L’option Vendor-Specific utilise Type 0. Ici, le texte impose une condition forte : avant de l’accepter, l’implémentation doit vérifier que l’OUI et le Kind désignent un mécanisme connu et qu’elle comprend entièrement les valeurs de négociation. La syntaxe n’est que la première marche.

Le registre distribue les noms, pas les capacités

L’OUI identifie l’organisation qui administre le sens. Le Kind d’un octet n’est pas normalisé entre OUI, et les Values sont propres à l’implémentation. L’OUI n’authentifie pas l’émetteur et n’accorde aucune permission opérationnelle. La RFC 1661 place d’ailleurs l’authentification éventuelle du pair après l’établissement du lien, alors que le paquet propriétaire peut arriver avant Opened.

La série CF0000 illustre la même séparation. Créée pour les fournisseurs logiciels sans OUI IEEE, elle a été fermée par RFC 5342, décision maintenue dans RFC 7042 sans modification technique du format. Le registre PPP de l’IANA conserve quelques lignes historiques. Elles prouvent une provenance numérique, pas la présence actuelle d’un code compatible.

Trois réponses, trois affirmations

Selon RFC 1661, Configure-Ack n’est valable que si toutes les options sont reconnaissables et toutes leurs valeurs acceptables ; la réponse recopie exactement la demande. Configure-Nak signifie que l’option est comprise mais que certaines valeurs ne conviennent pas. Configure-Reject signifie qu’elle est inconnue ou interdite à la négociation par l’administrateur.

Il faut donc conserver séparément le reçu de cadrage, le dictionnaire et sa version, l’autorité locale, la demande exacte et sa réponse, l’installation des paramètres, puis le premier trafic réellement traité. NCP Opened et un résultat applicatif corrélé appartiennent encore à des reçus ultérieurs. RFC 3772 a plus tard ajouté des numéros de protocoles propriétaires, tout en laissant leur sécurité aux protocoles eux-mêmes.

Les fiches RFC Editor, Datatracker et errata fixent l’histoire documentaire. Running-Code Primacy réserve la vérité d’exécution au système observé ; Minimum Initial Specification justifie une enveloppe commune étroite ; Reality Layers rappelle qu’un symbole ne devient pas un résultat.

Sources