Résumé

  • Pour transporter des sessions PPP sur Frame Relay, la RFC 3070 devait préciser l’identification de L2TP, l’association du tunnel à un PVC ou à un SVC, les extrémités du circuit et la taille admissible des paquets.
  • Le texte séparait l’abstraction portable du tunnel et le circuit qui la rendait exécutable ; le provisionnement, la qualité de service, la sécurité et le résultat pour l’usager restaient sous d’autres autorités.

L’indépendance avait besoin d’un mode d’emploi local

Publiée en février 2001, la RFC 3070 décrit le transport de paquets L2TP sur Frame Relay. Elle tient en peu de pages et semble relever d’une époque révolue, celle de l’accès commuté et des nuages de circuits virtuels. Pourtant, elle pose une question toujours actuelle : que signifie réellement l’indépendance à l’égard d’un média ?

L2TP séparait la session PPP de la technologie du réseau intermédiaire. Une session pouvait commencer près de l’abonné dans un concentrateur d’accès L2TP, le LAC, puis aboutir logiquement dans un serveur de réseau L2TP, le LNS. Le tunnel rendait ce parcours plus portable. Mais aucun paquet ne franchissait Frame Relay par la seule vertu de cette abstraction. Il fallait encore établir un circuit virtuel, désigner ses extrémités, reconnaître le protocole transporté et s’assurer que la trame était assez grande.

La RFC ne démontrait donc pas la disparition du média. Elle définissait le raccord qui permettait au média d’accueillir le tunnel.

La session n’était pas le circuit

La RFC 2661 distinguait déjà la connexion de contrôle L2TP et les sessions individuelles multiplexées dans le tunnel. Leurs identifiants appartenaient à la relation entre LAC et LNS. Frame Relay possédait sa propre réalité : le PVC, circuit virtuel permanent, était généralement repéré localement par un DLCI ; le SVC, circuit virtuel commuté, était établi par signalisation et pouvait utiliser des adresses X.121 ou E.164.

Ces identités pouvaient être associées, jamais confondues. Un identifiant de tunnel ne provisionnait pas un circuit d’opérateur. Un DLCI ne disait pas quel usager se trouvait dans une session PPP. Une adresse apte à établir un SVC ne prouvait pas que le LNS distant avait le droit de recevoir le trafic.

La différence apparaît dans les deux procédures de la RFC 3070. Dans le cas d’un SVC, la création du tunnel déclenchait l’établissement du circuit Frame Relay. Le déclencheur exact restait propre à l’implémentation et la signalisation Frame Relay n’était pas redéfinie. Dans le cas d’un PVC, le circuit devait être configuré administrativement entre les extrémités L2TP. Le DLCI pouvait venir de la configuration ou d’un dispositif d’autorisation, notamment des attributs de tunnel RADIUS décrits par la RFC 2868.

Dire « le tunnel est monté » résumait donc plusieurs décisions : un événement de contrôle, une autorisation et un circuit porteur avaient été mis en correspondance.

Une abstraction portable grâce à un identifiant très précis

L2TP devait pouvoir partager le même circuit Frame Relay avec d’autres protocoles. Le destinataire avait donc besoin d’une marque non ambiguë. La RFC imposait une adresse Q.922 suivie d’un en-tête SNAP : NLPID 0x80, identifiant d’organisation IANA 0x00-00-5E, puis identifiant de protocole 0x0007 pour L2TP.

Ces nombres ne sont pas de simples détails de registre. Ils forment la frontière publique entre les deux systèmes. Sans eux, le circuit pouvait transporter des octets, mais pas reconnaître sûrement un paquet L2TP parmi les autres. Le tunnel paraissait indépendant parce que son support recevait une étiquette exactement adaptée à ce support.

Les RFC 1490 et 2427 fournissaient le cadre plus général de l’encapsulation multiprotocole. La RFC 3070 n’effaçait pas ce cadre ; elle y occupait une place assignée. C’est une mécanique classique de l’Internet : la couche supérieure devient plus libre en s’appuyant sur une interface inférieure plus étroite et plus stable. La dépendance est rendue explicite et limitée, non supprimée.

Ce qui était retiré de la trame ne voyageait plus

Avant l’encapsulation L2TP, la trame PPP perdait son habillage physique : cadrage de liaison, mécanismes de transparence et séquence de contrôle. Le LNS n’avait pas besoin de reproduire toutes les marques électriques de l’accès initial. En revanche, le paquet reçu ne constituait plus une archive complète de son origine physique.

L’observateur pouvait vérifier le contexte du tunnel et de la session encore présent. Il ne pouvait pas déduire du seul contenu L2TP la qualité de la ligne d’accès, le cadrage exact ou les anomalies corrigées en amont. L’abstraction modifiait la nature des preuves disponibles.

Le MTU rappelait la même limite. En l’absence de fragmentation Frame Relay, la RFC calculait un minimum de 1 526 octets pour un datagramme L2TP conforme et recommandait 1 564 octets pour un pair PPP utilisant un MRU de 1 500 octets. Le moyen de faire respecter ou de négocier ces valeurs restait propre à l’implémentation.

Ainsi, le contrôle pouvait annoncer un tunnel sain tandis qu’un paquet utilisateur échouait sur une taille concrète. L’indépendance conceptuelle ne garantissait pas la traversée effective.

Ni qualité de service ni confiance par décret

La RFC 3070 ne normalisait pas la qualité de service de ce transport. Elle constatait l’existence de procédés propriétaires et renvoyait à d’éventuels travaux ultérieurs. Elle signalait aussi l’absence de mécanisme de sécurité Frame Relay standardisé pour cet usage et renvoyait aux considérations de sécurité de L2TP.

Ce silence délimitait une compétence ; il n’annulait ni les pertes, ni le délai, ni la congestion, ni la confidentialité. Le fournisseur pouvait mettre en service le circuit, le constructeur proposer une priorité, l’exploitant choisir une protection et mesurer la livraison. Aucun de ces pouvoirs ne découlait automatiquement de l’identifiant d’encapsulation.

Le contrôle restait réparti. L’IANA tenait les valeurs enregistrées. L’IETF décrivait l’interopérabilité. L’opérateur Frame Relay maîtrisait le circuit. Les administrateurs du LAC et du LNS configuraient le tunnel. Un serveur d’autorisation pouvait fournir des attributs. Le logiciel décidait comment déclencher l’appel ou appliquer les limites. L’usager, lui, subissait le résultat sans disposer de toutes les preuves du chemin.

Le successeur du protocole n’était pas le successeur du réseau

La RFC 3931 a ensuite généralisé L2TP version 3 pour des pseudowires capables de transporter davantage de services de couche deux. Cette évolution confirme l’intérêt de séparer le service émulé du réseau de paquets. Elle ne prouve ni la migration automatique des installations RFC 3070, ni la disparition de leurs dépendances.

Une norme peut devenir historique alors qu’un circuit reste exploité. Un opérateur peut retirer le support tandis que subsistent des attributs RADIUS, des sauvegardes de configuration et des habitudes de diagnostic. Pour écrire l’histoire, il faut donc demander non seulement quel texte était en vigueur, mais quelles dépendances exécutables et administratives commandaient encore le service.

Le principe du code en fonctionnement défendu par Lu Heng aide à placer la limite. Une implémentation active prouve qu’une interface définie peut fonctionner. Elle ne prouve pas que le circuit a été correctement provisionné, que ses extrémités sont légitimes, que le MTU couvre tous les usages ou que l’abonné reçoit le service promis. Sa grille des couches de réalité oblige de même à distinguer l’identifiant du tunnel, le DLCI configuré, la signalisation réussie, le paquet livré et l’expérience satisfaisante.

La force historique de la RFC 3070 vient de cette franchise. Elle a rendu L2TP indépendant du média en décrivant précisément ce que Frame Relay devait encore fournir. Le tunnel empruntait un circuit ; la robustesse de l’abstraction dépendait de la visibilité de cet emprunt.

Sources