Résumé

  • RFC 3437 permettait au LAC d’envoyer les options LCP souhaitées et admises au LNS ; après la négociation, le LNS renvoyait ses dernières Configure-Request émises et reçues.
  • Ces quatre AVP distinguaient préférence, capacité et trace du résultat. Ils ne prouvaient ni authentification, ni service, et leur caractère obligatoire pouvait sacrifier la disponibilité à l’observabilité.

Une autorité distante, un savoir local

Le LAC touchait la ligne physique. Il connaissait sa MRU, sa carte ACCM, les compressions PFC ou ACFC possibles et son FCS. Le LNS, à l’autre bout du tunnel, terminait pourtant la session PPP et pilotait LCP. Le L2TP d’origine ne transmettait que des indices grossiers — synchrone ou asynchrone, numérique ou analogique — insuffisants pour décrire l’interface.

RFC 3437, publié en décembre 2002, traite cette asymétrie. Son texte, sa notice, son dossier Datatracker, son historique, ses références, ses citations ultérieures et ses errata prouvent une norme publiée, pas son déploiement.

Le proxy n’était qu’un instantané

Dans PPP, LCP construit l’état du lien par Configure-Request, acceptation et rejet. Le framing de type HDLC rend les contraintes locales concrètes ; les extensions LCP et CHAP montrent que toute décision n’appartient pas au support.

Un LAC pouvait exécuter un Proxy LCP avant de livrer l’appel. Mais l’authentification relevait du LNS, la MRU pouvait refléter plusieurs limites et le pair pouvait rouvrir LCP plus tard. RFC 3437 autorisait donc le LAC à omettre les anciens AVP de proxy pour forcer le LNS à négocier ; les nouveaux AVP pouvaient aussi accompagner un résultat proxy.

Quatre AVP, pas un voyant unique

Dans ICCN ou OCCN, LCP Want Options (49) exprimait ce que le LAC désirait ; LCP Allow Options (50) bornait ce que l’interface supportait. Une option permise n’était pas nécessairement souhaitée, et un souhait ne liait ni le LNS ni le pair.

Une fois LCP achevé, Set-Link-Info rapportait LNS Last Sent LCP Confreq (51) et LNS Last Received LCP Confreq (52), chacun contenant le paquet LCP complet à partir du champ Code. Le mouvement comptait : contraintes locales vers le contrôleur, preuves de négociation vers le bord. Un LAC qui envoyait Want ou Allow devait savoir traiter le retour.

Ces paquets n’attestaient pas l’authentification, la configuration réseau, la comptabilité ou le trafic utile. Ils étaient des reçus de protocole, pas un reçu de résultat.

L’optionnel avait un coût

Les quatre AVP étaient non obligatoires par défaut. Un pair ancien pouvait les ignorer ; le bit M pouvait transformer l’incompréhension en arrêt de session. Le RFC déconseillait ce choix sauf impossibilité totale de fonctionner sans l’extension. La compatibilité préservait la disponibilité mais pouvait faire disparaître la preuve recherchée.

De nouveaux numéros furent attribués parce qu’une ancienne implémentation pouvait rejeter un AVP connu placé dans un type de message jadis interdit. Un attribut nouveau et optionnel était parfois plus sûr qu’un attribut familier au mauvais endroit. Le registre L2TP de l’IANA et celui des numéros PPP enregistrent la coordination, non l’usage.

Les AVP révélaient aussi des caractéristiques d’interface utiles à l’inférence de topologie. Des faits voisins apparaissaient déjà dans LCP : le risque changeait de forme et d’emplacement, pas de nature. RFC 3145, RFC 3193, RFC 3438 et RFC 3931 éclairent d’autres frontières L2TP sans prouver confidentialité ni service.

Le reçu durable

Les couches de réalité de Heng Lu séparent ici intention, contrainte déclarée, message observé, état LCP et résultat utilisateur. La primauté du code exécuté réserve aux tests le traitement des AVP inconnus et des renégociations. La spécification initiale minimale explique l’économie des quatre messages sans prétendre décrire l’intention des auteurs.

La leçon de RFC 3437 est sobre : la commande distante reste crédible si elle conserve le savoir local, la décision distante et le résultat observé comme trois objets distincts.

Sources