Résumé

  • RFC 1663 ajoutait à PPP un Numbered Mode facultatif. Une liaison qui le négociait obtenait une fenêtre bornée, un espace de séquence commun, des acquittements, des temporisateurs de retransmission et un retour explicite au mode UI en cas de désaccord.
  • Les deux récepteurs pouvaient annoncer des fenêtres différentes, mais pas des modulos différents. Le Magic-Number désignait celui qui lancerait SABM ou SABME ; il ne l’authentifiait pas. La compression des champs Address et Control était incompatible avec les informations que ces champs devaient désormais porter.
  • UA fermait l’échange d’établissement de la procédure numérotée. Authentification, mesure de qualité, configuration NCP, routage et résultat applicatif demeuraient des étapes distinctes, avec leurs propres preuves.

Quand la perte d’un paquet désaccordait les suivants

Le PPP ordinaire sur une liaison de type HDLC utilisait la trame Unnumbered Information. Les paquets formaient des datagrammes : une trame endommagée pouvait être rejetée sans que la liaison promette de la réinsérer dans un flux ordonné. Cette sobriété convenait à de nombreux usages.

Elle devenait coûteuse lorsque deux datagrammes partageaient un état. RFC 1663 prend l’exemple de la compression. La perte d’un paquet comprimé peut décaler le dictionnaire du destinataire ; les paquets suivants deviennent alors indéchiffrables malgré un FCS correct. Certaines méthodes savent réinitialiser leur contexte à peu de frais. D’autres gagnent à disposer, entre les deux voisins, d’une livraison fiable et ordonnée.

Le groupe PPP de l’IETF n’a pas imposé ce coût à toutes les liaisons. Publié en juillet 1994, RFC 1663 définissait l’option LCP 11, Numbered-Mode. Un pair la proposait pendant l’établissement et l’autre devait l’accepter. En l’absence d’accord, UI restait le comportement normal.

Cette faculté réduisait la décision commune à ce qui exigeait réellement l’interopérabilité. Deux équipements partageant un dictionnaire fragile pouvaient ajouter une boucle de reprise. Ceux qui préféraient des datagrammes indépendants n’avaient pas à adopter une fenêtre et des retransmissions devenues inutiles pour eux.

Deux champs cessaient d’être décoratifs

Le paquet PPP ne changeait pas entièrement. Protocol, Information, Padding, FCS et drapeaux gardaient leurs fonctions. Le mode numéroté transformait Address et Control selon la procédure LAPB d’ISO 7776. Une fois le mode actif, toutes les trames de la liaison devaient l’employer ; UI ne pouvait pas réapparaître au gré de chaque paquet.

La règle rendait impossible une optimisation familière. Address-and-Control-Field Compression supprimait normalement le couple constant ff 03. Dans Numbered Mode, ce couple n’était plus constant : il portait l’adresse de liaison et les informations de séquence. RFC 1663 interdisait donc de négocier ACFC. RFC 1662 formulait la limite générale : des valeurs Address ou Control différentes de la forme habituelle doivent être définies ou acceptées auparavant, et ne peuvent être escamotées comme des constantes.

Le FCS couvrait ces champs. Un FCS juste établissait la cohérence des bits reçus selon le tramage ; il n’établissait pas que les deux extrémités appartenaient encore au même épisode de négociation. Une trame peut être physiquement intacte et néanmoins incompatible avec l’état courant.

La fenêtre choisissait aussi l’alphabet des séquences

La valeur Window allait de 1 à 127. Elle annonçait combien de trames le récepteur pouvait conserver et combien l’émetteur pouvait laisser sans acquittement. La fenêtre exprimait une capacité, mais aussi une limite au travail incertain.

Au-dessous de 8, les numéros suivaient le modulo 8 ; à partir de 8, le modulo 128. Les pairs pouvaient offrir des fenêtres différentes, puisque leurs mémoires n’étaient pas nécessairement symétriques. Ils ne pouvaient pas employer des modulos différents. Une extrémité qui compte dans un cercle de trois bits et l’autre dans un cercle de sept bits ne discutent pas d’un débit : elles parlent deux syntaxes incompatibles.

Configure-Nak pouvait réduire la fenêtre offerte, jamais l’augmenter. Un récepteur modeste gardait ainsi le pouvoir de limiter sa charge sans promettre un tampon supplémentaire. La réponse ne pouvait pas non plus pousser l’offrant vers une représentation de séquence plus large qu’il n’avait pas choisie.

L’option annonçait également une adresse HDLC. Zéro devait être refusé avec une adresse convenable. Des règles de départage comparaient fenêtres et adresses ; le hasard n’intervenait que dans le cas résiduel où elles ne suffisaient pas. Cette procédure distribuait des rôles de liaison. Elle ne disait rien sur l’identité juridique ou opérationnelle des équipements.

Le plus petit Magic-Number prenait la parole

Numbered Mode exigeait la négociation du Magic-Number. Après l’accord LCP, le pair portant la valeur numériquement la plus faible envoyait SABM en modulo 8 ou SABME en modulo 128. L’autre répondait UA. Les deux côtés obtenaient un initiateur déterministe sans autorité extérieure.

La perte d’un message d’établissement ou de UA relevait du Restart Timer et des compteurs LCP. UA doit pourtant rester à sa place sémantique : il confirme l’établissement de la procédure numérotée avec le voisin. Dans l’architecture PPP, l’authentification, la détermination de la qualité et les NCP suivent l’établissement de la liaison. UA ne prouve donc ni l’acceptation d’un secret, ni une qualité suffisante, ni une adresse IP configurée, ni l’existence d’une route, ni l’exécution d’une requête par un service.

Le Magic-Number n’était pas davantage un justificatif d’identité. Il aidait à départager les pairs et à repérer un rebouclage. Il n’était ni une signature ni une autorisation. RFC 1663 ne traite pas des questions de sécurité ; la fiabilité d’une livraison adjacente et la confiance dans son émetteur restent deux constructions différentes.

La reprise commençait par reconnaître le désaccord

Un mécanisme fiable doit également définir le moment où son état partagé n’existe plus. RFC 1663 empêchait qu’une extrémité demeure indéfiniment numérotée tandis que l’autre était revenue à UI.

Une renégociation se déroulait encore en Numbered Mode. Si l’option échouait, la liaison revenait à UI avant l’authentification, la qualité et les NCP. Une implémentation capable de Numbered Mode mais actuellement non numérotée, recevant une trame non-UI au FCS correct, envoyait DM puis relançait immédiatement LCP. Une extrémité numérotée recevant DM revenait elle aussi à UI et émettait un nouveau Configure-Request.

Ainsi, un bon FCS ne ressuscitait pas un ancien état de contrôle. Le désaccord devenait visible sous la forme de DM et d’un nouvel épisode LCP.

Les tentatives étaient bornées. T1 fixait l’attente maximale d’une réponse à une trame d’information avant retransmission. RFC 1663 recommandait de l’adapter au temps aller-retour LAPB mesuré ; une formule de repli combinait longueur de trame, débit et temps de traitement. T3 signalait l’inactivité et devait dépasser T1. N2 plafonnait les transmissions d’une même trame ; son dépassement devait terminer la liaison, avec 3 comme valeur par défaut recommandée.

Trois n’était pas une loi générale du réseau. C’était la limite proposée pour cette boucle adjacente. L’épuisement de N2 ne diagnostiquait pas la cause du silence et ne fixait pas le budget de relance d’une transaction applicative.

Plusieurs liaisons ne formaient pas un faisceau par accident

Par défaut, des liaisons PPP parallèles étaient établies, configurées et terminées séparément. Un état de compression dépendant de l’ordre restait propre à chacune, sauf procédure supplémentaire pour les réunir.

RFC 1663 mentionnait un mécanisme ISO Multi-Link, mais déconseillait de l’implémenter et recommandait les travaux PPP Multilink devenus ensuite RFC 1990. Le Numbered Mode ordonnait et récupérait les trames sur une liaison membre. Multilink créait un espace de séquence pour réassembler des fragments distribués sur plusieurs membres. La présence du premier ne prouvait jamais celle du second.

Un acquittement numéroté appartient donc à une liaison, une adresse, un modulo et un état de négociation précis. On ne peut pas le transférer à une liaison parallèle, encore moins au-delà d’un routeur.

La valeur de l’acquittement venait de sa limite

Le registre IANA associe le numéro d’option LCP 11 à Numbered-Mode. Il stabilise un vocabulaire. Un Configure-Ack atteste l’acceptation de valeurs précises pour un épisode. SABM ou SABME, suivi de UA, atteste l’établissement de la procédure. Les suites de numéros, acquittements et retransmissions documentent la progression des trames de cette liaison. DM, un redémarrage LCP ou l’épuisement de N2 documente la perte de cet état.

Chaque échelon apporte une preuve, sans devenir le système entier. L’identité relève des protocoles d’authentification ; la qualité, de ses mesures et de sa politique locale ; la configuration réseau, des NCP ; la joignabilité, du routage ; le résultat, de l’application.

RFC 1663 n’a pas garanti que des données avaient atteint leur destination ultime. Il a fait quelque chose de plus modeste et vérifiable : deux voisins volontaires partageaient une syntaxe de séquence, bornaient leurs trames en attente, acquittaient leur progression et disposaient d’une sortie commune quand leur état divergeait. L’acquittement restait fiable parce qu’il ne prétendait pas savoir ce qui se passait au-delà de la liaison.

Sources