Résumé

  • La RFC 1473 distinguait une table de configuration d’une table opérationnelle. Écrire open injectait un événement dans l’automate IPCP ; ce n’était pas une attestation que l’état Opened avait été atteint.
  • Un changement de compression ne prenait effet qu’au redémarrage suivant du lien. Avant la fin de la négociation, les valeurs de protocole et de slots étaient indéfinies ; après, elles restaient des paramètres, non des reçus de trafic.

Publiée en juin 1993, la RFC 1473 définissait le groupe IP de la MIB PPP. Elle avait choisi peu d’objets : ceux nécessaires à la gestion des pannes ou de la configuration, utiles en pratique et non simplement dérivables d’autres données.

Cette économie empêchait une confusion commode. Le désir de l’administrateur, l’état de l’automate et le passage d’un paquet n’avaient pas la même source.

La commande open ne prédisait pas l’automate

pppIpConfigAdminStatus exprimait l’état immédiatement souhaité du protocole IP. Une écriture open injectait l’événement administratif Open dans l’automate IPCP ; close injectait Close.

L’agent pouvait accepter l’ordre sans que le pair accepte les options. La couche inférieure pouvait être absente, l’échange expirer ou l’IPCP rester hors de l’état Opened. Le reçu d’administration prouvait l’entrée, pas la sortie de l’automate.

La RFC 1661 conserva cette architecture : chaque protocole réseau possède son NCP, ouvert ou fermé indépendamment. L’ouverture du LCP ou d’un autre NCP ne remplace donc pas l’observation de l’IPCP.

Le changement visait la prochaine vie du lien

pppIpConfigCompression indiquait ce que le nœud local tenterait de négocier : aucune compression ou la compression d’en-têtes TCP/IP de Van Jacobson. La phrase décisive de la RFC fixait l’activation au prochain redémarrage du lien.

Le nouveau réglage coexistait ainsi avec une session qui pouvait encore utiliser l’ancien. Pour relier intention et effet, il fallait conserver la génération de configuration, l’identité du redémarrage, les paquets IPCP et leur résultat.

La RFC 1332 définissait l’option IP-Compression-Protocol. La compression était désactivée par défaut. Chaque extrémité devait demander séparément la capacité de recevoir des paquets compressés pour obtenir un usage bidirectionnel. Une seule valeur globale aurait effacé cette asymétrie.

Un entier pouvait être exact et dépourvu de sens

La table opérationnelle présentait pppIpOperStatus, les protocoles de compression dans les deux directions et les Max-Slot-Id local et distant. Ces paramètres n’étaient disponibles qu’après la négociation et l’arrivée de l’IPCP à Opened.

Avant cet état, leur contenu était explicitement indéfini. La valeur renvoyée dépendait de l’implémentation.

Il ne s’agissait pas seulement d’une donnée ancienne. Une valeur ancienne peut être rattachée à une session passée ; une valeur indéfinie ne porte aucune affirmation sur la session présente. Zéro pouvait être un défaut, un résidu ou un choix d’interface. Le type ASN.1 correct n’ajoutait pas la provenance absente.

Après Opened, les champs restaient directionnels. Local-to-remote décrivait l’émission locale ; remote-to-local, la réception. Sans compression Van Jacobson, Max-Slot-Id devait être zéro. Mais avant Opened, ce même zéro ne permettait pas de conclure à un accord sans compression.

Opened autorisait le trafic, sans le constater

La RFC 1332 exigeait la phase Network-Layer Protocol et l’état IPCP Opened avant la communication de paquets IP. La RFC 1661 précisait que les paquets du protocole correspondant seraient portés après l’ouverture du NCP et rejetés avant.

Opened était donc une condition réelle, mais pas un paquet. Il ne prouvait ni progression d’un compteur, ni compression effective, ni reconstruction correcte, ni route disponible, ni réponse applicative.

La RFC 1144 expliquait le gain attendu sur les liens lents. Cette promesse technique ne raccourcit pas la chaîne de preuves : option négociée, paquet compressible, paquet comprimé, décompression correcte et livraison utile restent des faits distincts.

Protéger la commande ne prouvait pas son effet

La séparation de la table de configuration facilitait son placement dans une vue MIB distincte. La RFC avertissait que la configuration et le contrôle PPP présentaient un risque, et évoquait lecture seule, vues protégées ou absence d’accès. Les documents voisins répartissaient aussi le périmètre : RFC 1471 pour le LCP, RFC 1472 pour la sécurité.

Une automatisation fidèle doit garder l’auteur de la demande, la valeur relue, la génération de configuration, le redémarrage, les propositions des deux directions, les transitions Opened et les observations de trafic. Sinon une préférence en attente devient « active », un champ indéfini devient « mesuré » et un état devient « livré ».

La leçon de la RFC 1473 tient dans cette discipline : la gestion commence par marquer le moment où un nombre n’a pas encore droit de témoigner.

Sources