Résumé

  • IPComp traite chaque datagramme séparément et sans perte. Aucun dictionnaire transmis par le paquet précédent n’est nécessaire, car IP tolère la perte et le désordre.
  • Si la charge compressée augmentée de l’en-tête IPComp de quatre octets n’est pas plus petite que la charge d’origine, le datagramme doit partir sous sa forme originale, sans en-tête IPComp.
  • Le CPI est un index directionnel choisi par le décompresseur et interprété avec l’adresse de destination. Il ne prouve ni l’identité, ni la négociation, ni le bénéfice de la compression.

Une capacité n’est pas une obligation d’exécution

La présence d’une fonction dans une négociation pousse à chercher son empreinte dans chaque paquet. IPComp sépare ces deux plans. L’association décrit le mode, l’algorithme, les paramètres et le CPI qu’un destinataire saura employer. Elle ne promet pas que toute charge utile sera transformée.

La raison tient aux données elles-mêmes. Un bloc répétitif se replie facilement ; un petit message de contrôle peut grossir ; une image ou une archive déjà comprimée résiste. La configuration commune ne peut pas connaître le résultat de chaque entrée future. Elle fournit donc une grammaire pour les succès, tandis que le datagramme conserve le droit de rester ordinaire.

Le protocole 108 dans un en-tête IPv4 ou IPv6 signifie qu’un paquet se présente sous la forme IPComp. Son absence ne dit pas pourquoi la forme originale a été choisie. Confondre cette absence avec un échec d’association revient à transformer une décision locale prévue par la norme en alerte imaginaire.

Le bon ordre : réduire avant de rendre les octets aléatoires

Le RFC 2393 de 1998 situait IPComp à proximité d’IPsec. Après chiffrement, une charge paraît aléatoire et offre peu de redondance à une couche inférieure. La compression doit donc précéder l’authentification et le chiffrement sortants, ainsi que la fragmentation. À l’arrivée, elle attend la réassemblage, l’authentification et le déchiffrement.

Cette chaîne fixe aussi ce qui reste visible. En IPv4, l’en-tête externe et ses options ne sont pas comprimés. Dans un tunnel IPsec, l’en-tête IP interne appartient à la charge externe et peut l’être. En IPv6, les en-têtes que des nœuds intermédiaires doivent examiner restent hors de la zone comprimée ; un Fragment Header précède IPComp.

L’architecture ne demande aucun état entre datagrammes. Chaque résultat doit pouvoir être décomprimé seul. Un paquet perdu ne rend pas le suivant illisible, et un paquet réordonné ne transporte pas un dictionnaire indispensable à ceux qui l’avaient dépassé. Cette indépendance rend aussi les mesures modestes : le ratio du paquet précédent n’est qu’un indice, jamais une garantie.

L’optimisation devait payer ses quatre octets

Le RFC 3173 exprime la règle de non-expansion avec une comparaison complète. La charge compressée n’est pas jugée seule. On lui ajoute l’en-tête IPComp de quatre octets. Si l’ensemble n’est pas plus petit que la charge originale, le paquet original est transmis et aucun en-tête IPComp n’est inséré.

Deux échecs sont ainsi évités. Le récepteur ne dépense pas de cycles pour défaire une transformation sans gain. Et un paquet qui tenait sous la MTU ne devient pas fragmenté parce qu’un mécanisme d’optimisation l’a agrandi.

Les implémentations peuvent refuser l’essai avant même cette comparaison. Un seuil numérique peut écarter les petits paquets. Une suite d’échecs peut alimenter un compteur adaptatif qui saute plusieurs essais avant de retester. Un algorithme peut détecter une entrée peu compressible et s’arrêter tôt. Ces paramètres appartiennent au code local.

Le RFC 2394 illustre ce principe avec DEFLATE. Des essais informels conduisent à déconseiller les tampons de moins de 90 octets. Ce nombre n’est ni une limite universelle d’IPComp ni une propriété du format sur le fil. Il ne s’applique pas automatiquement à un autre algorithme, processeur, lien ou mélange de trafic.

Une capture sans IPComp peut donc correspondre à un seuil, un saut adaptatif, une détection d’incompressibilité ou un résultat qui n’amortit pas l’en-tête. La capture montre la branche finale ; elle ne contient pas la cause locale.

Le CPI parlait au destinataire

La forme comprimée remplace le champ Protocol ou Next Header externe par 108. Son petit en-tête conserve l’ancien Next Header, réserve un octet Flags et porte un CPI de 16 bits. Après une décompression réussie, le destinataire retire IPComp, restaure le sélecteur d’origine et replace la charge reconstruite.

Le CPI n’est pas un identifiant mondial de l’algorithme. Une plage désigne des transformations connues, une autre sert à la négociation et une dernière à l’usage privé. Surtout, chaque nœud peut choisir indépendamment le CPI qu’il veut recevoir. Le paquet sortant utilise la valeur choisie par son décompresseur. C’est l’association du CPI et de l’adresse de destination qui sélectionne les caractéristiques utiles.

Ce caractère local explique un avertissement du RFC 3173. Si plusieurs sessions entre les mêmes nœuds réemploient le même CPI connu tout en portant des durées de vie ou des compteurs adaptatifs distincts, les associations deviennent difficiles à distinguer. Une valeur négociée est préférable quand l’unicité compte. Le numéro sert à retrouver un état ; il ne certifie pas l’autorité qui l’a créé.

Aucun algorithme par défaut

Une IPComp Association réunit CPI, mode, algorithme et paramètres. Elle peut viser tous les paquets entre deux nœuds ou seulement certaines sessions. Les deux directions sont indépendantes et peuvent choisir des algorithmes différents.

La norme n’impose aucun algorithme commun à toutes les implémentations et ne fournit aucun défaut. Dire « IPComp » ne suffit donc pas à supposer DEFLATE. Le choix doit être explicite.

Le RFC 3173 a remplacé le texte initial principalement pour clarifier la négociation IKE. IKEv2 a ensuite précisé qu’une demande pouvait offrir plusieurs algorithmes, mais qu’une réponse en acceptait au plus un. Un nœud ne doit pas employer une transformation qui n’a pas été proposée et acceptée.

Dans IKEv2, l’association de compression virtuelle n’a pas de vie hors de la Child SA ESP ou AH qui la contient. Elle disparaît avec elle, sans Delete propre. Cela ne fusionne pas les pouvoirs : la négociation IPComp reste séparée des paramètres cryptographiques. Un CPI accepté n’authentifie pas le paquet.

Ce qui rétrécit devient moins inspectable

Sans IPsec, la compression peut compliquer le filtrage ou la comptabilité d’un routeur frontal. L’ancien Protocol a changé de place, et les ports de transport se trouvent dans la charge comprimée. Un intermédiaire qui ne partage pas l’association ne peut plus lire ces champs comme avant.

Ce n’est pas de la confidentialité. Les octets ne deviennent pas secrets ; le dispositif perd seulement le contexte nécessaire pour les reconstruire et appliquer sa politique. Lorsqu’un environnement exige de filtrer ou de compter tous les paquets, le RFC 3173 demande un moyen sûr de communiquer l’association au filtre.

Une exploitation honnête distingue donc la politique configurée, l’association acceptée, l’essai de compression, la décision d’émettre 108, la recherche du CPI et la restauration finale. « Compression activée » ne couvre aucune de ces preuves à lui seul.

IPComp a ainsi donné une discipline rare à l’optimisation. La capacité commune était durable ; son usage devait rester révisable paquet par paquet. Le format publié fixait le minimum. Le trafic réel gardait la décision future.

Sources