Résumé

  • Une valeur inconnue dans le champ Protocol de PPP ne prouvait pas que le lien entier était défaillant. Quand LCP était à l’état Opened, le récepteur devait répondre par Protocol-Reject, code 8.
  • La réponse nommait le protocole refusé sur deux octets et recopiait une partie bornée du paquet déclencheur, sans en-têtes de liaison ni FCS et sans dépasser la MRU du pair.
  • Le rejet d’un NCP pouvait rester une anomalie tolérable, RXJ+ ; le rejet de LCP était RXJ-, une contradiction catastrophique qui supprimait le plan de contrôle commun.

Le désaccord commençait après l’accord

Le paradoxe n’apparaissait pas pendant l’établissement du support physique. Il commençait lorsque les deux extrémités avaient déjà porté LCP à l’état ouvert et qu’un paquet arrivait avec une valeur Protocol inconnue. Le lien savait transporter des trames PPP ; il ne savait pas nécessairement traiter tout ce que l’autre extrémité voulait y multiplexer.

Dès 1989, le RFC 1134 présentait PPP comme un moyen de transporter les datagrammes de plusieurs protocoles de couche réseau. LCP gouvernait le lien commun, tandis qu’une famille de Network Control Protocols devait configurer les usages particuliers. Cette architecture permettait à plusieurs protocoles de coexister. Elle exigeait donc une réponse plus fine que « tout fonctionne » ou « tout est coupé ».

Protocol-Reject apportait cette finesse. Dans l’état Open de LCP, un récepteur confronté à un protocole inconnu devait envoyer un paquet LCP de code 8. Le RFC 1331, publié en 1992, précisait en outre une nuance décisive : si le protocole était connu mais que son NCP n’était pas encore ouvert, le paquet devait être abandonné silencieusement. L’inconnu relevait d’un défaut de capacité ; le connu arrivé dans le mauvais état relevait du séquencement.

Le silence n’avait donc pas une signification unique. Il pouvait signaler un NCP fermé, un état LCP inadapté, une perte ou un comportement non conforme. Inversement, un Protocol-Reject ne démontrait ni une rupture physique ni un échec d’authentification. Il bornait le désaccord à une valeur précise du champ Protocol.

Une petite réponse portait une preuve typée

Le format stabilisé par le RFC 1661 est volontairement compact. Le champ Code vaut 8. L’Identifier doit changer à chaque Protocol-Reject envoyé. Le champ Rejected-Protocol, long de deux octets, reprend exactement le champ Protocol du paquet refusé.

Rejected-Information commence avec le champ Information du paquet initial. Il exclut les en-têtes de couche liaison et le FCS. Surtout, il doit être tronqué pour respecter la Maximum-Receive-Unit établie par le pair. Le mécanisme renvoie donc le contexte utile sans fabriquer, au nom du diagnostic, une réponse plus grande que ce que le destinataire a accepté de recevoir.

Cette recopie n’est pas une archive de trame. Elle peut être incomplète et n’inclut pas les éléments externes à l’information PPP. L’Identifier n’est pas non plus un identifiant universel d’incident. La preuve permet d’attribuer le refus à un protocole et à un paquet de contrôle ; elle ne certifie pas tout le trajet.

Le RFC 1548, en 1993, puis le RFC 1661, en 1994, ont conservé cette construction. Sa longévité tient à une règle simple : un message d’erreur doit rester plus petit que le contrat de transport qui le porte et assez précis pour que son destinataire sache quoi arrêter.

L’obligation portait sur l’émetteur fautif

Après réception du rejet, le RFC 1661 impose d’arrêter l’envoi des paquets du protocole indiqué « à la première occasion ». Cette formule ne promet pas qu’aucun paquet déjà en file ou en vol n’apparaîtra encore. Elle interdit cependant de transformer une déclaration explicite d’incompatibilité en boucle de tentatives indéfinies.

Les NCP donnent un sens concret à cette portée. Le RFC 1332 définit IPCP pour établir et configurer IP sur PPP. Le RFC 5072 remplit ce rôle pour IPv6CP. Ce sont des exemples de la famille architecturale, non la preuve qu’une liaison observée les implémente. Si l’un de ces plans de contrôle est rejeté, le service réseau correspondant ne peut pas être tenu pour disponible. Un autre protocole ne survit que s’il est, de son côté, reconnu et correctement configuré.

Protocol-Reject ne peut être envoyé que lorsque LCP est Opened. Reçu dans un autre état, il devrait être abandonné silencieusement. Cette règle empêche un refus sans contexte partagé de piloter la machine d’états. Le droit de dire « je ne prends pas ce protocole » naît seulement après l’accord sur le canal qui transporte cette phrase.

Le nom du protocole déterminait la gravité

Le RFC 1331 classait la réception d’un rejet selon deux événements. RXJ+ couvrait un refus acceptable, par exemple celui d’un NCP. L’événement restait dans le périmètre de l’exploitation normale : l’implémentation cessait le type de paquet concerné, sans devoir condamner LCP.

RXJ- couvrait la contradiction catastrophique. Le texte cite le Protocol-Reject de LCP lui-même : une erreur irrécupérable qui termine la connexion. La forme du paquet n’a pas changé ; l’objet du refus, oui. Refuser un locataire peut laisser l’immeuble debout. Refuser le langage qui permet aux deux gardiens de gérer l’immeuble détruit la possibilité même d’isoler le problème.

Cette asymétrie empêche une lecture naïve de la résilience. Le lien peut rester ouvert après le rejet d’un NCP, mais l’application qui dépend de ce NCP peut être totalement indisponible. La continuité du support et la continuité du service sont deux mesures distinctes.

Le registre décodait les nombres, pas les équipements

Le registre IANA des numéros PPP classe aujourd’hui le code LCP 8 comme Protocol-Reject et publie les affectations du champ Protocol. Il permet de traduire un nombre en nom normalisé. Il ne prouve pas qu’un logiciel implémente ce protocole, qu’un NCP a atteint Opened, qu’une liaison l’utilise aujourd’hui ou que des paquets ont été livrés.

Le RFC 3818 a fait évoluer la politique d’allocation des espaces PPP vers un processus de consensus IETF. C’est une preuve de gouvernance d’un espace extensible, pas un recensement de déploiement. Pour passer du registre à la réalité, il faut joindre capture, états LCP/NCP, configuration et comportement après le rejet.

Sources