Résumé

  • RFC 3355 plaçait L2TP sur un circuit virtuel ATM AAL5, mais chaque PDU L2TP devait tenir dans un seul PDU AAL5 ; le MTU du support bornait donc le tunnel et toutes les sessions PPP qui l’empruntaient.
  • Le choix d’encapsulation, l’établissement, la sécurité et la coupure restaient des faits du support. Un format négocié ne prouvait pas le succès des sessions, et la disparition d’un SVC les terminait.

Le mot « tunnel » suggère que ce qui se trouve dessous n’a plus besoin d’être regardé. Pour l’utilisateur PPP, les commutateurs ATM et la signalisation pouvaient effectivement disparaître. Mais l’unité complète devait toujours franchir une ouverture d’une taille déterminée, portée par un circuit qui pouvait être établi ou supprimé. L’infrastructure cachée conservait donc un pouvoir concret.

RFC 3355, publié sur la voie des normes en août 2002, définissait le transport de L2TP sur ATM Adaptation Layer 5. La spécification de base de L2TP voulait rester largement indépendante du média et ne demandait qu’une connectivité point à point orientée paquets. Un circuit virtuel AAL5 pouvait fournir ce service entre le LAC et le LNS.

La règle qui fixait la frontière était simple : un PDU L2TP devait être transporté dans un seul PDU AAL5. L’enveloppe ne pouvait donc pas être ignorée. Le MTU de la connexion AAL5 limitait celui du tunnel, puis le MRU de toutes les connexions PPP utilisant ce tunnel.

Cette propagation rendait visible une dépendance collective. Plusieurs sessions pouvaient paraître indépendantes, chacune avec ses propres utilisateurs et négociations. Elles partageaient néanmoins la même limite extérieure. Une session trop ambitieuse ne créait pas de place supplémentaire parce que L2TP dissimulait ATM.

La conformité imposait la prise en charge d’un MRU PPP d’au moins 1500 octets. RFC 3355 recommandait aussi de pouvoir accueillir un paquet IP d’au moins 9180 octets dans le PDU PPP. Il s’agissait d’une capacité d’implémentation et d’une recommandation, non d’un constat sur un circuit actif. Le PVC pouvait être provisionné autrement, le SVC négocier d’autres paramètres ou le pair PPP choisir un MRU inférieur.

Le service AAL5 attendu était bit-synchrone, bidirectionnel et point à point. Le VC pouvait être permanent, construit par provisionnement, ou commuté à la demande. Le mode message non assuré, sans livraison de données corrompues, était obligatoire. L’interface présentait des octets entiers.

Préserver une limite de message et vérifier une longueur ou un CRC ne transformait pas AAL5 en preuve de livraison. Ces contrôles ne donnaient ni identité de l’émetteur, ni confidentialité, ni acceptation par le contrôle L2TP. Ils validaient une propriété précise de l’enveloppe reçue.

Le contenu de cette enveloppe était nommé de deux manières. Avec LLC/SNAP, chaque PDU indiquait explicitement L2TP au moyen de l’identifiant IANA. Avec le multiplexage par VC, cet en-tête disparaissait : les deux extrémités avaient convenu que le circuit transportait L2TP. L’identité dépendait alors du contexte du circuit.

Le support LLC sur PVC était obligatoire. LLC sur SVC et le multiplexage VC restaient optionnels. Sur un PVC, les deux extrémités devaient être configurées de la même façon. Deux équipements capables de L2TP pouvaient donc ne pas comprendre les mêmes octets si leur accord de circuit différait.

Pour un SVC, la signalisation ATM négociait ce choix au moyen des éléments B-LLI. L’appelant proposait LLC, VC-multiplexé ou les deux dans un ordre de préférence. Si les deux étaient proposés et l’appel accepté, l’appelé en choisissait exactement un. Une offre contenant seulement une méthode non prise en charge devait être rejetée.

Cette négociation produisait un reçu borné : une méthode d’interprétation avait été choisie pour cet établissement. Elle ne prouvait pas que la connexion de contrôle L2TP serait opérationnelle, que PPP authentifierait un utilisateur, que les tailles conviendraient ou que l’application recevrait des données.

Le cycle de vie révélait encore mieux le pouvoir du support. Lorsqu’un tunnel reposant sur un SVC était réinitialisé selon L2TP, les deux extrémités devaient supprimer le SVC et toutes les sessions utilisateur du tunnel se terminaient. Un nouveau client pouvait provoquer une nouvelle tentative, mais celle-ci ne continuait pas silencieusement les anciennes sessions.

Dans l’autre sens, la notification de suppression du SVC AAL5 imposait la destruction du tunnel et le retour de la connexion de contrôle à l’état inactif. Une panne du support remontait ainsi dans la machine d’état intérieure. L’abstraction n’était pas une barrière contre le cycle de vie.

Après un échec d’établissement, l’implémentation pouvait considérer le pair inaccessible. Les critères permettant de prendre puis de lever cette décision étaient locaux. Quand aucune session n’était active, chaque extrémité pouvait aussi supprimer le SVC. Un état « inaccessible » ou « inactif » devait donc être accompagné de sa couche, de sa cause observée et de sa génération.

La qualité de service n’effaçait pas cette provenance. Plusieurs connexions AAL5 pouvaient séparer des catégories de clients. Le multiplexage inverse d’un tunnel sur plusieurs VC était renvoyé à des travaux futurs. Les paramètres d’un PVC pouvaient être convenus et ceux d’un SVC demandés lors de l’appel. Une demande de trafic ne prouvait pas le service réellement livré.

La sécurité restait une autre dépendance. RFC 3355 avertissait qu’une attaque contre le réseau ATM pouvait compromettre le tunnel. Il recommandait des en-têtes d’authentification, des charges chiffrées ou des services de sécurité ATM. Un PID correct et un CRC valide ne constituaient pas une protection cryptographique.

Les RFC voisins situent les responsabilités. RFC 2661 définit tunnels et sessions L2TP ; RFC 1661, PPP et son MRU ; RFC 2684, les formes LLC et VC sur AAL5 ; RFC 2364, PPP directement sur AAL5 ; RFC 2331, la signalisation ATM. RFC 3070 cartographie L2TP sur Frame Relay et montre qu’un autre support possède une autre jointure. RFC 3193 ajoute l’état IPsec. RFC 4459 analyse plus tard les problèmes généraux de MTU dans les tunnels.

Le registre IANA des paramètres L2TP conserve les valeurs coordonnées. Il établit la signification d’une attribution, pas son usage dans une implémentation ou la survie d’une session. Aucun de ces textes ne démontre un déploiement, un débit, un incident ou une réussite de RFC 3355.

La leçon historique tient dans cette limite : une abstraction retire des détails du champ de vision, pas de la réalité. L2TP permettait aux sessions PPP de ne pas connaître ATM. Le VC AAL5 gardait pourtant le dernier mot sur la taille de l’enveloppe, son identité et la disparition des sessions lorsque le support était supprimé.

Sources