Résumé

  • Chaque option CCP décrit ce que le récepteur accepte de décompresser ; les deux sens peuvent donc choisir des algorithmes différents, ou laisser un seul sens sans compression.
  • Configure-Ack valide une demande précise, 0x00FD signale un datagramme compressé sans nommer l’algorithme, et Reset-Ack clôt un échange de synchronisation : aucun de ces signes ne prouve à lui seul l’intégrité, la récupération des pertes ou la livraison applicative.

Le détail le plus moderne de RFC 1962 n’est pas la compression. C’est la modestie de son accord. Le protocole CCP ne demande pas à deux machines de devenir symétriques ; il leur demande seulement d’annoncer, chacune, ce qu’elle peut recevoir sans ambiguïté.

PPP doit déjà se trouver dans la phase des protocoles de couche réseau avant tout échange CCP. Un paquet CCP arrivé plus tôt devrait être éliminé silencieusement. Et même après cela, aucun datagramme compressé ne doit circuler avant que CCP n’atteigne l’état Opened.

Deux récepteurs, deux décisions

Une option de configuration CCP indique les algorithmes et paramètres que le récepteur est disposé ou capable d’utiliser pour décompresser les données de son pair. La machine peut en proposer plusieurs ; une seule méthode principale est retenue pour ce sens. L’autre sens suit sa propre négociation.

Cette orientation explique une asymétrie assumée. La mémoire, le coût, la vitesse ou les licences peuvent différer. Une extrémité peut recevoir du LZS et envoyer sans compression ; l’autre peut accepter une autre méthode. La liaison ne doit pas transformer une différence locale en panne globale.

Le refus est déterministe. Une option inconnue entraîne Configure-Reject. Une méthode connue mais accompagnée de valeurs inacceptables entraîne Configure-Nak avec des valeurs acceptables. Si toutes les propositions sont rejetées, la compression n’est pas activée dans ce sens, tandis que la liaison continue sans elle.

L’accusé de réception n’est pas un certificat

CCP reprend le mécanisme d’échange de LCP. Dans RFC 1661, Configure-Ack est la réponse positive à un Configure-Request valide et précis. Il établit que le pair a accepté cet encodage d’options à cet instant. Il n’atteste pas tout l’avenir de la liaison.

Pour relier cet Ack à une trame ultérieure, il faut conserver l’identifiant, les octets de l’option, les paramètres, le sens, l’époque d’état et l’arrivée effective des deux automates dans Opened. Une renégociation peut intervenir. Une extension propriétaire peut être reconnue par son OUI tout en étant interprétée différemment. RFC 2153 fournit une enveloppe générale aux extensions de fournisseur ; il ne transforme pas l’OUI en preuve d’interopérabilité.

RFC 1915 rappelle aussi un contexte historique : les travaux CCP et ECP avançaient au milieu de méthodes brevetées et d’une procédure de variance. Ce dossier raconte un passage institutionnel, pas l’installation d’un algorithme dans une machine donnée.

Le champ de protocole cache volontairement l’algorithme

Quand CCP est ouvert, 0x00FD signifie « datagramme compressé ». Pour une compression gérée séparément sur chaque lien physique d’un ensemble multilink, 0x00FB sert aux données et 0x80FB au contrôle. Ces valeurs figurent toujours dans le registre IANA.

Mais RFC 1962 précise que 0x00FD ne révèle pas l’algorithme. Comme un seul algorithme principal existe par sens, le récepteur associe la trame à l’état négocié courant. Une capture privée du dialogue CCP, du sens ou de l’époque ne suffit donc pas pour choisir le décodeur.

Le mot « compressé » ne garantit pas non plus un gain de taille. Certains contenus s’allongent. Si la sortie dépasse l’unité d’information PPP, l’émetteur peut envoyer le paquet natif non compressé ou utiliser une fragmentation prévue par le profil. Le marqueur décrit une classe de traitement, pas un résultat économique.

La détection de désynchronisation appartient au profil

Un dictionnaire partagé est fragile : une seule perte peut faire diverger tous les blocs suivants. Le CCP générique ne porte pas un contrôle d’intégrité universel. RFC 1962 exige que chaque algorithme sache déterminer s’il transporte correctement les données, ou qu’il impose un transport fiable comme le mode numéroté de RFC 1663. Il recommande fortement une validation des octets décompressés ou la détection d’une paire désynchronisée.

Les profils montrent pourquoi le détail compte. RFC 1974 peut employer numéros de séquence, LCB ou CRC et plusieurs historiques. RFC 1967 place des indications de réinitialisation dans son propre format. Une valeur 0x00FD isolée ne dit pas lequel de ces contrôles existait, encore moins s’il a réussi.

Il faut donc séparer classification et validation : la trame relevait-elle du compresseur négocié ? Puis le mécanisme propre à ce profil a-t-il confirmé la continuité et l’intégrité ?

Réinitialiser ne ressuscite pas les paquets

Reset-Request, code 14, et Reset-Ack, code 15, servent à signaler une décompression défaillante dans un sens sans affecter l’autre. Après l’envoi de la requête, le récepteur jette les paquets compressés de ce sens jusqu’à recevoir un Ack valide portant l’identifiant attendu ; il peut retransmettre la requête.

Le pair efface alors son compresseur d’émission et répond. Le premier récepteur remet son décompresseur à l’état initial. Cette danse recrée un point de départ commun. Elle ne reconstitue pas les datagrammes jetés pendant l’attente.

Un Reset-Ack ne prouve donc ni que la prochaine trame passera son CRC, ni qu’un autre historique est sain, ni que le transport est fiable. La retransmission éventuelle relève d’une autre couche. Le service peut se rétablir ; CCP n’en produit pas le reçu.

La leçon historique

La primauté du code en fonctionnement formulée par Heng Lu invite à ne pas confondre publication et exécution. RFC 1962 fixe un langage commun étroit : types de paquets, traitement des options, état d’ouverture et remise à zéro. Le choix de l’algorithme, des paramètres et même de compresser reste local.

La chaîne de preuve suit la même discipline : phase réseau, demande par sens, Ack correspondant, état Opened, compresseur réellement choisi, marqueur de trame, contrôle d’intégrité, échange de reset, première sortie de nouveau valide, réception finale et effet applicatif. Le câble est commun ; les preuves ne le sont pas.

Sources