Résumé

  • PPPMuxCP permettait à chaque récepteur d’offrir, dans une direction précise, la capacité de recevoir des trames PPP multiplexées. Le succès de la négociation autorisait le format sans obliger l’émetteur à l’utiliser.
  • Le PID par défaut donnait au récepteur une règle pour reconstruire un identifiant de protocole omis. Il ne démontrait ni PFF à zéro, ni omission effective, ni octet économisé.
  • Le gain dépendait des sous-trames réellement assemblées, de l’attente en file, du MRU, des limites de taille, des erreurs et de l’ordre avec MP, CCP et ECP. Une capacité n’est ni une mesure ni un résultat applicatif.

L’économie ne commençait qu’avec une seconde enveloppe évitée

PPP sait transporter de nombreux protocoles sur une liaison point à point, mais chaque paquet encadré séparément paie son propre contour. L’encadrement de type HDLC, le champ de protocole et le contrôle de trame occupent des octets même lorsque certaines compressions PPP ont été négociées. Dans un tunnel L2TP, la répétition de l’enveloppe devient encore plus visible pour une succession de petits paquets.

RFC 3153 proposait de conserver les paquets PPP comme unités logiques tout en les rangeant comme sous-trames dans une même trame extérieure. Un petit délimiteur indique la longueur de chaque sous-trame et si son identifiant de protocole est présent. L’amortissement porte sur l’enveloppe, pas sur le contenu.

Mais l’émetteur ne peut regrouper que ce qui se trouve déjà dans sa file. S’il attend un autre paquet pour mieux remplir la trame, le premier paquet attend avec lui. Le texte met donc en balance la baisse du coût par paquet et le délai de multiplexage puis de démultiplexage. Le format rend une économie possible ; il ne déclare pas que cette économie vaut toujours l’attente.

Une mesure sérieuse commence avec les octets effectivement émis. Elle compte les délimiteurs, les champs de protocole présents ou absents, la taille de la trame extérieure et l’encapsulation environnante. Elle ajoute le temps passé en file et les conséquences d’une perte. La seule présence de l’option dans une configuration ne fournit aucun de ces nombres.

Le consentement du récepteur fixait une limite, pas une cadence

Le contrôle appartient à PPPMuxCP. Pendant la phase NCP, un récepteur peut proposer sa capacité à recevoir le nouveau format. Tant que le pair n’a pas formulé cette offre, l’émetteur ne doit pas lui envoyer de trame multiplexée. Et comme la réception est négociée séparément dans chaque direction, un accord aller ne vaut pas accord retour.

Une fois l’échange réussi, le pouvoir change de côté. L’émetteur peut choisir les paquets qu’il regroupe, ou continuer à les envoyer seuls. RFC 3153 précise que la réussite de PPPMuxCP ne crée aucune obligation de transmettre des trames multiplexées.

Ce détail empêche de transformer l’état de contrôle en fait de trafic. « PPPMux actif » peut désigner une offre reçue, un échange acquitté, une politique locale chargée, un compteur de données non nul ou seulement l’étiquette simplifiée d’une interface d’administration. Il faut demander dans quelle direction, sur quel pair, à quelle heure et avec quelles trames de données.

Le reçu minimal joint donc l’échange Configure à une capture ultérieure portant la valeur de protocole de la trame multiplexée. Sans cette jointure, on connaît la grammaire que le récepteur accepte, pas la phrase que l’émetteur a prononcée.

Le PID par défaut était une règle d’interprétation conditionnelle

PPPMuxCP négocie toujours un PID par défaut. Le récepteur offre la valeur qu’il appliquera lorsque la première sous-trame ne porte pas son propre identifiant de protocole. Si le premier paquet correspond à cette valeur, l’émetteur peut mettre PFF à zéro et retirer le champ, ce qui économise un ou deux octets selon la compression PPP ordinaire.

Il peut aussi conserver le champ. Le RFC ne l’oblige pas à prendre l’optimisation disponible. Le PID négocié prouve donc que les deux côtés disposent d’une convention de reconstruction ; il ne prouve pas que PFF a été effacé sur le fil.

Pour les sous-trames suivantes, un PFF nul reprend le dernier PID explicite. L’émetteur suit cet état dans Last_PID, le récepteur dans Last_rcvd_PID. Un PFF à un transporte une nouvelle valeur et déplace l’état ; au début de la trame, la valeur négociée sert de point de départ.

Cette mécanique est petite mais séquentielle. Pour savoir quel protocole a été reconstruit, il faut lire les sous-trames dans l’ordre. Un compteur de trames extérieures ne révèle ni les champs omis ni les changements de PID. Deux émetteurs peuvent avoir le même nombre de trames multiplexées et des économies différentes.

La limite la plus haute n’était pas la meilleure cible

Le délimiteur associe PFF à LXT et LEN. LXT choisit une longueur courte ou étendue ; LEN borne les octets de la sous-trame. L’algorithme d’exemple ajoute une limite locale, MAX_SF_LEN, puis s’arrête si le prochain paquet la dépasse, si l’agrégat franchirait le MRU négocié ou si la file est vide.

Un temporisateur peut constituer un quatrième arrêt. Il évite qu’un paquet attende indéfiniment une compagnie qui n’arrivera pas. Le document conseille aussi d’envisager une taille de trame multiplexée très inférieure au MRU lorsque le délai et les erreurs de paquet l’exigent.

Le MRU est ainsi une barrière de validité, pas un objectif de rendement. MAX_SF_LEN décrit les candidats acceptés par une politique locale, pas la taille optimale. Le temporisateur décrit le prix maximal d’une attente choisie, pas une propriété négociée avec le récepteur.

Plus de sous-trames peuvent mieux amortir l’enveloppe. Elles peuvent aussi faire attendre le premier paquet et réunir davantage de conséquences sous la perte ou l’endommagement d’une seule trame extérieure. Le débit, le taux d’erreur, la rafale de trafic et la sensibilité de l’application déplacent le compromis.

Le récepteur devait restituer l’ordre, pas seulement les morceaux

À la réception d’une trame 0x0059, le démultiplexeur lit les sous-trames successivement, reconstitue le PID si nécessaire et remet chaque paquet à la logique PPP. Si une longueur dépasse les octets encore disponibles, la dernière sous-trame est abandonnée. La valeur fautive peut pourtant provenir de cette sous-trame ou d’une précédente : le point de détection n’est pas forcément le point de corruption.

Le format ne peut pas être emboîté dans lui-même et les trames LCP n’ont pas le droit d’y entrer. Surtout, ni l’émetteur ni le récepteur ne doivent réordonner les paquets selon qu’ils voyagent seuls ou dans un agrégat.

Une preuve d’ordre doit donc réunir les deux voies. Elle conserve l’arrivée des trames extérieures, la place des paquets autonomes, les limites internes et l’ordre de remise après reconstruction. « Trois paquets extraits » ne dit pas s’ils ont dépassé un paquet voisin qui n’avait pas été multiplexé.

Même une reconstruction parfaite reste locale au décodeur. Une couche suivante peut abandonner le paquet ou l’application peut ne jamais l’observer. La sortie PPP n’est pas une confirmation de service.

Multilink, compression et chiffrement imposaient une géométrie

Dans un faisceau Multilink PPP, PPPMux se négocie pour le faisceau et non pour chaque liaison membre. À l’émission, le multiplexage précède l’encapsulation Multilink : l’en-tête MP éventuel se trouve donc à l’extérieur. Une trame Multilink ne peut pas devenir une sous-trame multiplexée.

CCP et ECP ajoutent des étages. PPPMux s’exécute après leurs versions au niveau du faisceau, mais avant MP et leurs versions par liaison. Une implémentation incapable de placer PPPMux au-dessus d’un CCP ou ECP par liaison doit rejeter cette forme lorsque PPPMux est négocié.

Cet ordre détermine les octets vus par chaque fonction. Une liste de fonctions prises en charge ne prouve pas leur composition. Une capture effectuée avant MP et une capture sur la liaison membre ne montrent pas le même objet. Un acquittement ECP ne prouve pas davantage que la trame observée a été chiffrée correctement.

L’audit doit nommer son point d’observation et reconstruire la pile, faute de quoi deux équipements « compatibles » peuvent appliquer les mêmes fonctions dans des ordres incompatibles.

L’absence de nouvelle menace n’ajoutait aucune protection

La section sécurité dit que RFC 3153 n’impose pas de considération supplémentaire au-delà de PPP et des schémas de compression d’en-tête. Cette phrase limite la nouveauté de la spécification. Elle ne fournit ni authentification, ni intégrité, ni confidentialité, ni protection contre le rejeu.

Une longueur mal formée, un désaccord de parseur ou un état PID divergent peut rester un incident opérationnel même s’il ne constitue pas une nouvelle classe de menace. La sécurité dépend encore de l’authentification PPP, du chiffrement réellement négocié, des contrôles de trame, du rejet des entrées invalides et de la conduite des couches suivantes.

Le parseur qui accepte une trame a prouvé qu’il comprend le format. Il n’a pas prouvé que l’émetteur est digne de confiance ni que le paquet restauré doit commander une action.

La spécification commune s’arrêtait avant le choix local

RFC 3153 fixait fermement ce qui devait être commun : l’offre préalable du récepteur, les valeurs de protocole, le sens des indicateurs, les longueurs, l’ordre de reconstruction et la place parmi les autres fonctions PPP. Il laissait ensuite à l’émetteur la décision locale d’utiliser ou non l’option pour le trafic présent.

C’est une forme de changement volontaire à l’échelle du paquet. Ne pas regrouper un paquet admissible n’était pas une invalidité. Envoyer le format à un récepteur qui ne l’avait pas offert l’était. La frontière commune protégeait l’interopérabilité sans prétendre connaître la meilleure décision de file.

Cette architecture appelle une histoire à plusieurs reçus. La négociation atteste la possibilité. La capture atteste l’usage. Le décodage atteste la reconstruction. Les mesures attestent les octets et le temps. L’application atteste seule son résultat.

Le legs de RFC 3153 ne tient donc pas dans une promesse universelle d’efficacité. Il tient dans une formulation plus honnête : le récepteur pouvait dire « je saurai le lire », et l’émetteur gardait encore la responsabilité de décider « je vais l’utiliser maintenant ».

Sources