Résumé

  • Dans les champs hérités TCP_SPACE et NON_TCP_SPACE de RFC 2509, zéro désigne l’identifiant de contexte maximal : l’identifiant 0 reste donc un contexte disponible.
  • La sous-option 3, longue de trois octets, permet à RFC 3544 de fixer explicitement à zéro le nombre de contextes TCP ou non-TCP et de désactiver cette classe.

Le piège tient au nom du champ. TCP_SPACE et NON_TCP_SPACE ne comptaient pas les contextes ; ils indiquaient la valeur maximale de leur identifiant. Une limite égale à zéro laissait donc l’identifiant CID 0 dans l’espace. Pour une configuration minimale, cela pouvait suffire. Mais aucun des deux champs ne permettait d’exprimer « ne compresser aucun paquet de cette famille ».

Publiée en juillet 2003 comme Proposed Standard, RFC 3544 a révisé l’option de négociation PPP introduite par RFC 2509 sans changer cette ancienne sémantique. Sa sous-option 3 apporte la distinction manquante : type 3, longueur 3 octets, puis un paramètre d’un octet. La valeur 1 signifie zéro contexte TCP ; la valeur 2, zéro contexte non-TCP. Cette sous-option remplace la valeur correspondante de TCP_SPACE ou NON_TCP_SPACE. Présenter les deux paramètres désactive la compression de tous les paquets.

Ce choix préserve la compatibilité au lieu de redéfinir zéro. Les anciens champs gardent leur sens, tandis qu’un signal supplémentaire porte l’intention qui leur manquait. Changer la signification des bits aurait contraint anciens et nouveaux pairs à interpréter différemment une même valeur.

Deux protocoles de contrôle, deux négociations

PPP négocie ses paramètres de liaison au moyen de protocoles de contrôle réseau. RFC 3544 définit le même format d’option pour IPCP en IPv4 et IPV6CP en IPv6. Chaque négociation configure la compression des paquets dont l’en-tête réseau extérieur correspond à cette version. Une compression IPv4 acceptée et une compression IPv6 acceptée sont donc deux résultats du plan de contrôle, pas un interrupteur universel.

Nuance importante : IPv4 et IPv6 partagent l’espace des identifiants de contexte alors que leurs valeurs sont négociées séparément. Si elles diffèrent, le moteur de compression doit allouer dans un pool commun et le décompresseur doit examiner l’état du contexte pour choisir les bons paramètres. TCP et le groupe non-TCP/UDP/RTP, eux, n’utilisent pas le même espace. Ce sont des contraintes de fonctionnement prévues par le protocole ; elles ne prouvent pas qu’un pair donné a réellement configuré ou utilisé ces fonctions.

RFC 3544 ajoute aussi la sous-option RTP améliorée de type 2, qui remplace la sous-option RTP 1 au lieu de s’y ajouter. Avec neuf valeurs de champ protocolaire PPP, ces options indiquent au récepteur comment classer une trame et quelles formes négociées sont autorisées. Le champ protocolaire sert au démultiplexage ; la sous-option exprime un choix de configuration.

Une négociation ne raconte pas tout le trajet

Après une négociation réussie, l’option autorise certains identifiants de protocole. Elle ne montre pas qu’une implémentation a envoyé une trame compressée, que l’autre extrémité l’a décodée, que le datagramme a été livré, ni que sa taille a diminué. Ces faits se situent à des étapes différentes. L’échange de configuration prouve un ensemble de paramètres convenu, pas la réception d’un paquet.

Le texte signale lui-même une ambiguïté voisine : RFC 1332 ne précise pas si l’option décrit les capacités de l’émetteur ou du récepteur. RFC 3544 indique que, conformément à la pratique, ses auteurs supposent qu’une Config-Req décrit le décompresseur du pair qui l’envoie. C’est une hypothèse explicitement formulée, non une clarification normative de RFC 1332. Lui donner une portée supérieure effacerait la réserve du document.

Le plan de données a sa propre condition. IPHC emploie le codage différentiel pour TCP et RTP ; les paquets dépendent alors d’un contexte partagé entre compresseur et décompresseur. PPP ne réordonne pas les paquets et les protections contre le réordonnancement sont donc désactivées par défaut. Si Multilink PPP multiclasses ou un autre mécanisme peut les réordonner, les paquets d’un même contexte doivent rester dans l’ordre. Négocier un format ne supprime pas cette contrainte de transport.

La leçon historique est circonscrite : l’évolution d’un protocole exige parfois un second signal parce que la valeur la plus intuitive possède déjà un sens valide. RFC 3544 a maintenu le champ, ajouté une surcharge explicite et laissé la capacité, l’envoi, le décodage, la livraison et le gain de performance comme autant de faits distincts à vérifier.

Sources