Résumé

  • Dans PPP, un Configure-Ack n’était pas une contre-offre polie : il devait reprendre sans changement l’identifiant, l’ordre et le contenu des options de la dernière demande.
  • L’accord LCP se construisait dans les deux sens. Un Nak proposait des valeurs recevables, un Reject retirait une option de la négociation, et l’état Opened exigeait d’avoir à la fois envoyé et reçu un Ack.

Dire oui sans toucher au texte

Un équipement annonce par exemple la taille maximale des trames qu’il souhaite recevoir. Son voisin comprend la demande, préfère une valeur voisine et la place dans Configure-Ack. Pour un négociateur humain, la correction paraît mineure. Pour PPP, elle annule la réponse.

Le RFC 1661 ne laisse aucune latitude : l’Ack doit porter l’identifiant de la dernière Configure-Request et restituer les options dans le même ordre, sans les modifier. Il n’est permis que si chaque option est reconnue et chaque valeur acceptable.

Cette répétition exacte donne une fonction probatoire au paquet. Si l’acquittement pouvait améliorer la proposition, l’émetteur devrait deviner s’il reçoit une approbation, une nouvelle offre ou une configuration hybride. Une perte, une retransmission ou deux demandes qui se croisent suffiraient à faire diverger les mémoires. Avec une copie exacte, la question est étroite : ces octets précis ont-ils été acceptés ?

L’Identifier rattache la réponse à une tentative. Il change quand les options changent ou lorsqu’une réponse valable clôt la demande précédente ; une retransmission peut le conserver. Ce petit numéro ne prouve ni l’identité ni la bonne foi du pair. Il empêche surtout qu’une ancienne conversation acquière une autorité nouvelle.

Le désaccord disposait de deux formes

Configure-Nak intervient lorsque l’option est comprise et négociable, mais que sa valeur ne convient pas. Le paquet écarte les options déjà acceptables, conserve celles qui posent problème et peut leur associer une valeur que son émetteur accepterait. Une politique locale peut également l’amener à signaler une option obligatoire absente de la demande.

Le Nak ne transforme pas la demande en cours. Il fournit une piste pour le prochain tour. L’autre extrémité reste libre d’émettre ou non une nouvelle Configure-Request ; si elle change le contenu, elle change aussi l’identifiant. La nouvelle proposition devra encore recevoir un Ack identique.

Configure-Reject dessine une limite différente. L’option est inconnue, non implémentée ou exclue de la négociation par l’administration locale. La réponse reproduit l’option rejetée et invite le demandeur à la retirer du prochain essai. Pour une option booléenne dépourvue de valeur alternative, Reject est la seule réponse négative cohérente.

PPP séparait ainsi trois actes que les interfaces résument volontiers par « négociation » : accepter ce qui a été demandé, indiquer un terrain possible, refuser d’ouvrir ce terrain. Le pair ne pouvait convertir aucun de ces actes en pouvoir de modifier la politique locale.

Deux directions, deux preuves

Chaque extrémité envoie sa propre Configure-Request. Sauf règle particulière de l’option, la demande concerne le sens de réception de son émetteur. A décrit donc à B les conditions sous lesquelles A recevra ; B formule séparément les siennes pour le sens inverse.

Les messages peuvent se croiser. A peut avoir reçu l’Ack de sa proposition tout en examinant encore celle de B. Le RFC 1171 appelait déjà cette situation Ack-Received : l’accord reçu n’efface pas l’accord qui reste à donner.

Le RFC 1331 formule ensuite le seuil d’ouverture : la phase d’établissement n’est achevée qu’après qu’un Configure-Ack a été envoyé et reçu. La présence d’un signal physique ou le succès d’un seul échange ne permet donc pas à une machine de déclarer toute la liaison ouverte.

Cette double comptabilité admet l’asymétrie réelle. Les capacités de réception, les exigences d’authentification, la compression ou le traitement des caractères de contrôle peuvent différer. L’interopérabilité ne demande pas que les deux équipements se ressemblent ; elle demande que chaque sens dispose d’un état accepté et vérifiable.

L’absence d’une option signifiait le défaut

Une Configure-Request n’est pas un inventaire complet. Elle énumère les changements souhaités par rapport aux valeurs par défaut ; le RFC 1661 déconseille même d’y inscrire une option déjà au défaut. Une option absente possède donc un sens positif : sa règle standard continue de s’appliquer.

Pour l’exploitation, cette économie crée une obligation. Conserver seulement le paquet ne suffit pas à reconstruire la configuration effective. Il faut ajouter les défauts pertinents et connaître le sens auquel chaque option s’applique.

Les options d’une demande sont évaluées ensemble. Ack en accepte la liste entière ; Nak ne rapporte que les valeurs contestées ; Reject ne rapporte que les options hors négociation. L’échange garde ainsi une frontière atomique sans imposer à un équipement de révéler toutes ses capacités.

Une grammaire de secours restait lisible

Certaines options modifient l’encapsulation elle-même. Si A commence à compresser les champs parce qu’il croit l’accord acquis alors que B attend encore le format par défaut, les paquets de contrôle risquent de devenir aussi incompréhensibles que les données.

Le RFC 1548, puis RFC 1661, gardent une voie stable : les paquets LCP de configuration, de terminaison et Code-Reject sont envoyés comme si aucune option n’était active. Les compressions des champs Address, Control et Protocol ne s’y appliquent pas.

Cette règle ne force pas l’accord. Elle garantit que le désaccord conserve une langue commune. L’optimisation du trafic ne doit pas détruire le canal qui permet de revenir à une interprétation sûre.

La négociation n’était pas infinie

Une liaison peut perdre des paquets. Le Restart timer protège Configure-Request, et Max-Configure borne les tentatives sans réponse valable. RFC 1661 exige que cette limite soit configurable et recommande dix émissions par défaut.

Un autre échec produit beaucoup de réponses mais aucun accord. Max-Failure compte les Naks successifs ; la valeur recommandée est cinq. Au-delà, de nouveaux Naks deviennent des Rejects et l’équipement cesse d’ajouter ses propres options souhaitées. Le protocole préfère réduire l’espace de discussion plutôt que d’entretenir indéfiniment un échange sans convergence.

Ces compteurs ne diagnostiquent ni une attaque ni une panne certaine. Ils donnent à chaque extrémité une raison locale et observable d’arrêter une tentative dont les preuves restent insuffisantes.

Une liaison LCP ouverte n’était pas encore un réseau

Les quatre codes de configuration apparaissent dès le RFC 1134 de novembre 1989. RFC 1171, RFC 1331, RFC 1548 et la norme de base de juillet 1994 ont conservé la structure tout en précisant les phases.

Le support physique devient d’abord disponible. LCP règle ensuite les paramètres indépendants de la couche réseau. Une authentification négociée se déroule après cet établissement. Enfin, un Network Control Protocol distinct ouvre chaque protocole réseau. IP ne peut circuler parce qu’un unique Ack LCP a été observé.

La portée de la preuve reste donc limitée. Configure-Ack ne garantit ni identité, ni authentification réussie, ni adresse IP, ni route, ni service. Il atteste seulement que son émetteur accepte une proposition LCP exacte.

Le registre PPP de l’IANA conserve aujourd’hui Request, Ack, Nak et Reject sous les codes 1 à 4 et maintient l’espace des options. Cette permanence atteste un vocabulaire coordonné, pas l’usage actuel ni la conformité de tous les produits.

Une autorité étroite plutôt qu’un chef de liaison

PPP rendit l’accord précis en lui refusant les raccourcis. L’acceptation devait être identique, la contre-offre portait un autre nom, le refus avait sa propre portée, les deux directions tenaient des comptes séparés et les couches supérieures devaient obtenir leurs propres preuves.

Aucun registre central ne choisissait la taille, la compression ou l’authentification d’une liaison particulière. Aucun pair ne pouvait commander l’autre. La norme partageait quelques tests reproductibles, puis laissait les exigences chez l’extrémité qui en assumait le risque.

Sources et limites

RFC 1134, RFC 1171, RFC 1331, RFC 1548 et RFC 1661 fondent l’histoire, les formats, les états et les limites de convergence ; l’IANA fonde les assignations actuelles. Ils ne mesurent ni déploiement contemporain, ni conformité des fournisseurs, ni performance, ni délai opérationnel universel. L’analyse de cette mécanique comme une autorité bilatérale minimale est une interprétation, non une citation des RFC.