Résumé

  • Le NLPID 0xcf annonce PPP après l’en-tête Q.922, mais un autre premier octet ne devient un protocole PPP compressé que si PFC est actif et si le NCP correspondant a déjà été négocié.
  • Plusieurs réponses portant le même identifiant LCP et des adresses de trame différentes signalent un branchement multipoint possible ; une encapsulation équivalente après négociation NCP impose de revenir à Link Establishment.

Une ligne de supervision « circuit actif » ne dit pas quelle conversation traverse le circuit. Elle ne dit pas non plus combien d’interlocuteurs répondent, quelle grammaire ils appliquent, ni s’ils se souviennent encore d’un accord antérieur. Cette distance entre présence physique et état partagé donne à RFC 1973 son intérêt historique.

Publié en juin 1996, le document place PPP dans un circuit Frame Relay configuré en point à point. LCP, les NCP, l’authentification et la compression de PPP supposent deux pairs. Frame Relay offre des circuits virtuels, mais peut aussi exposer des conditions multipoints. Une encapsulation valable devait donc protéger une machine d’états à deux participants contre une infrastructure qui ne prouvait pas, à elle seule, cette dualité.

Une ambiguïté reconnue, non masquée

PPP s’appuyait ordinairement sur une trame de type HDLC issue d’ISO 3309. On avait espéré faire cohabiter ce format et Frame Relay sur une même liaison. RFC 1973 explique pourquoi cette ambition a été abandonnée : Q.922 étend l’adresse d’un à deux ou quatre octets, et la structure des sous-champs DLCI n’est pas toujours distinguable de l’interprétation ISO 3309. Le récepteur ne pouvait pas trouver la frontière avec certitude.

La solution fut de rendre l’enchaînement explicite : Flag 0x7e, Address Q.922, Control, NLPID 0xcf, puis champ PPP Protocol. L’adresse et le contrôle appartiennent au transport Frame Relay. 0xcf choisit l’encapsulation PPP. Le champ suivant choisit LCP, un NCP ou un protocole transporté. Chaque étape réduit l’ambiguïté syntaxique ; aucune ne garantit à elle seule l’identité, l’authentification ou la livraison.

Le même raisonnement interdit Address-and-Control-Field-Compression. Dans le format HDLC-like, les deux valeurs sont constantes et peuvent être omises. Dans Frame Relay, elles ne le sont pas et le tissu de commutation peut les modifier. Les comprimer reviendrait à traiter un contexte de livraison variable comme un décor répétitif.

PFC transforme un octet en question d’état

Protocol-Field-Compression répond à une autre contrainte. Elle réduit le champ PPP Protocol de deux octets à un. RFC 1973 remarque qu’après suppression du NLPID et compression du Protocol, le champ Information s’aligne sur 32 bits ; la compression est donc recommandée lorsqu’elle améliore le débit.

La réception suit alors un arbre précis. Le premier octet après l’en-tête vaut zéro : la trame relève de RFC 1490. Il vaut 0xcf : le NLPID PPP est explicite. Il est non nul et différent de 0xcf : il ne peut être attendu comme protocole PPP compressé que si PFC a été activé et si le NCP associé a déjà abouti. Sinon, la trame doit encore être interprétée selon RFC 1490.

La valeur observée n’est donc pas autonome ; elle est lue avec la mémoire de la négociation. Pour éviter une collision lorsque PFC est actif, la valeur PPP Protocol 0x00cf est réservée. Le texte autorise éventuellement son emploi pour indiquer qu’un autre paquet PPP Protocol suit, mais ne lui attribue aucun statut de preuve supérieure. Les registres IANA conservent cette séparation entre NLPID 0xCF et PPP Protocol 00cf réservé.

Le même identifiant, deux adresses

Les premiers paquets LCP portent cf-c0-21 après l’en-tête : le NLPID PPP puis le Protocol LCP non compressé c021. La reconnaissance d’un Configure-Request fait entrer le lien dans Link Establishment. C’est un début vérifiable, pas une négociation accomplie.

La norme décrit ensuite un défaut de câblage logique. Si un accès supposé point à point alimente par erreur un réseau multipoint ou un groupe multicast, plusieurs nœuds peuvent répondre au même Configure-Request. Des réponses partageant le même Identifier LCP mais provenant d’adresses de trame différentes devraient déclencher une indication de mauvaise configuration.

L’Identifier relie les réponses à une requête. Les adresses différentes apportent la pluralité. Il faut les deux faits. Une réponse unique ne garantit pas l’unicité du pair ; un DLCI n’est pas une identité organisationnelle globale ; et l’absence d’alerte ne vaut pas preuve négative, car certaines implémentations peuvent être incapables de journaliser ou de rapporter l’adresse de trame.

Refaire LCP plutôt que nourrir un trou noir

Pendant Link Establishment, aucun paquet portant un autre NLPID ne peut être émis ; s’il arrive, il doit être silencieusement rejeté jusqu’à la phase Network-Layer Protocol. Une donnée issue d’une autre grammaire ne doit pas prendre de vitesse sur une configuration PPP encore inachevée.

Après réussite d’un NCP, l’apparition d’une encapsulation RFC 1490 équivalente pour le même protocole réseau change de sens. Elle suggère que l’autre extrémité a perdu l’état PPP. Le lien doit revenir à Link Establishment et envoyer un nouveau LCP Configure-Request. Sans ce retour visible, une extrémité continuerait à suivre un accord que l’autre ne reconnaît plus, et les paquets disparaîtraient dans un trou noir.

Cette réaction ne révèle pas la cause. Elle ne prouve ni redémarrage, ni reconfiguration, ni incident de commutation. Elle ne récupère pas les données déjà rejetées et ne promet pas la réussite du second échange. Elle convertit seulement un symptôme ambigu du plan de données en tentative observable sur le plan de contrôle.

L’échec conduit à un choix local. Si la configuration PPP ou une fonction négociée telle que l’authentification est indispensable, l’implémentation peut passer en Termination. Sinon, après épuisement de Max-Configure, elle doit n’envoyer que l’encapsulation RFC 1490. Continuer avec moins de propriétés et s’arrêter pour les préserver sont deux résultats différents.

Les contraintes de la machine réelle

La liaison doit être full-duplex, permanente ou commutée. Les signaux Frame Relay peuvent alimenter les événements Up et Down de LCP, mais leur défaillance ne doit pas empêcher PPP de fonctionner correctement. Magic Number et PFC sont recommandés. Le MRU initial est de 1600 octets ; le MTU réseau ne devrait pas dépasser 1500 sauf négociation explicite d’un MRU pair d’au moins 2048.

Certains commutateurs n’acceptaient que des trames de 262 octets. Les implémentations devaient donc pouvoir limiter les paquets LCP à 259 octets avant la fin de la négociation, réservant la place du NLPID et du Protocol. XID et Inverse ARP ne sont pas exigés sur ces liens PPP, leur fonction étant fournie par la négociation NCP. Ce sont des choix d’interopérabilité circonscrits.

RFC 2427 a ensuite remplacé RFC 1490 et RFC 1294 pour l’encapsulation multiprotocole générale ; il n’a pas rendu RFC 1973 obsolète. Les normes et registres établissent des formats, non l’usage actuel, les paramètres d’un fournisseur ou la réussite d’un service. Enfin, RFC 1973 déclare que les questions de sécurité ne sont pas discutées. On ne peut donc déduire du framing aucune confidentialité, intégrité ou authentification.

Sources