Résumé

  • RFC 1993 autorise plusieurs paquets PPP d’origine dans une trame comprimée, ou un seul paquet réparti sur plusieurs trames.
  • Une sortie qui grossit reste transmise : la retirer romprait l’historique commun dont dépend la suite du flux.
  • Un décompactage réussi ne prouve ni la livraison de tous les paquets, ni l’identité du pair, ni la sécurité, ni l’issue applicative.

Deux horloges de frontières

FZA fait fonctionner deux découpages simultanés. Le premier appartient à la liaison : chaque trame doit tenir dans le champ Information de PPP. Le second appartient au flux comprimé : les paquets d’origine sont reconstruits quand l’indicateur de fin de paquet apparaît dans les données comprimées. Ces deux horloges n’ont aucune obligation de sonner ensemble.

Une trame peut donc transporter un ou plusieurs paquets PPP encapsulés. Si la représentation comprimée — éventuellement plus grande que l’entrée — dépasse le MRU du pair, elle continue dans une autre trame. Ce n’est pas le bord physique qui renseigne le décompresseur sur la fin du paquet. La marque est à l’intérieur du flux. Et cette marque ne remet pas l’historique à zéro.

Les valeurs PPP 0x00FD et 0x00FB indiquent respectivement un Compressed Datagram et un Link Compressed Datagram. La seconde place la compression à l’extérieur de PPP Multilink, afin que chaque liaison physique puisse disposer de son propre contexte. L’enregistrement IANA confirme l’attribution des numéros ; il ne confirme ni un déploiement, ni la version, ni la bonne santé de l’historique, ni l’identité du pair.

Le coût immédiat d’un accord futur

Le mot « compression » suggère un gain à chaque passage. RFC 1993 dit autre chose : FZA peut dilater les données jusqu’à deux pour un et produit typiquement environ 1,01 pour un sur des données déjà comprimées. Malgré cela, la sortie dilatée est envoyée.

La décision protège un état partagé. L’émetteur et le récepteur doivent faire évoluer leur historique avec exactement la même suite ordonnée. Si l’émetteur escamotait une sortie peu avantageuse, son dictionnaire avancerait sans que celui du récepteur puisse l’imiter. Les références ultérieures n’auraient plus la même signification. Le protocole accepte donc une petite perte présente pour préserver l’intelligibilité future.

Lorsque cette sortie excède le MRU, elle traverse plusieurs trames. C’est la conséquence logique du choix : la taille du conteneur ne peut pas décider quelles parties de l’histoire commune méritent d’exister. Ce qui semble être un mauvais résultat de compression sur un paquet peut être la condition de la compression des suivants.

Une ponctuation explicite au bout de la trame

Il reste à retirer le remplissage sans confondre un octet utile avec une longueur. RFC 1993 exige donc l’option Self-Describing-Padding de RFC 1570 pendant l’établissement LCP. Les octets de remplissage sont numérotés dans l’ordre ; avec trois octets, la séquence est 1, 2, 3, et le dernier indique combien en supprimer. Si le dernier véritable octet pourrait être lu comme une longueur de remplissage, l’émetteur ajoute un remplissage pour lever l’ambiguïté.

Cette ponctuation ne signe pas le message. Elle permet seulement d’identifier une terminaison locale. Une séquence valide n’authentifie pas le pair et ne garantit pas l’intégrité de bout en bout. Une séquence invalide peut conduire au rejet silencieux de la trame, mais ce contrôle syntaxique n’est pas un verdict de sécurité.

La condition que le décompresseur ne peut pas certifier

RFC 1993 suppose une livraison fiable et dans l’ordre. Cette propriété vient de la liaison ; FZA ne la fabrique pas. RFC 1663 explique pourquoi une perte brise un dictionnaire continu et décrit un mode fiable négocié séparément. C’est un contexte nécessaire, pas une fonction cachée de RFC 1993.

On peut dès lors limiter chaque preuve à sa portée. Le numéro de protocole atteste une classe d’encapsulation. Le remplissage cohérent atteste un suffixe retirable. La décompression atteste que le décodeur a traité les octets reçus. Seule une observation de liaison peut établir que tous les éléments requis sont arrivés dans l’ordre ; seule l’étape PPP suivante peut établir que le paquet reconstruit a été remis au protocole prévu. L’identité, l’autorisation, la confidentialité et l’action de l’application restent encore au-delà.

La section de RFC 1993 consacrée à la sécurité précise que le sujet n’est pas traité. L’absence actuelle de errata enregistrés ne signifie ni absence de défaut, ni déploiement courant. Le statut Informational ne transforme pas davantage le texte en preuve d’exécution. La leçon durable est sobre : dans une transformation avec état, la limite visible du conteneur n’est pas nécessairement la limite logique de la chose que l’on mesure.

La méthode publiée par Heng Lu aide à maintenir ces séparations : observer d’abord le comportement du code et n’accorder à chaque reçu que l’autorité de son point d’observation. Ici, une fin de trame ne parle pas pour une fin de paquet, et un décompresseur ne parle pas pour l’application.

Sources

Les faits de protocole proviennent des RFC et du registre. Les trois essais de Heng Lu exposent la méthode d’analyse ; ils ne documentent pas le mécanisme FZA.