Protocole L2TP

par Étienne GALLET DE SANTERRE

Ingénieur de recherche en réseaux informatiques,
ENST Bretagne

1. Historique................................................................................................... TE 7 579 - 2
1.1 Point-to-Point Tunnel Protocol : PPTP......................................................... — 2
1.1.1 Protocole ............................................................................................. — 2
1.1.2 Établissement du tunnel et des sessions.......................................... — 3
1.2 Layer 2 Forwarding : L2F............................................................................. — 3
1.2.1 Protocole ............................................................................................. — 3
1.2.2 Établissement du tunnel et des sessions.......................................... — 3
2. Terminologie.............................................................................................. — 3
2.1 L2TP Access Concentrator (concentrateur d’accès L2TP) ........................ — 3
2.2 LNS : L2TP Network Server (serveur réseau L2TP) .................................. — 4
2.3 Tunnel L2TP.................................................................................................. — 4
2.4 Session L2TP................................................................................................ — 4
2.5 Connexion de contrôle ................................................................................ — 4
2.6 AVP : Attribute Value Pair (paire attribut-valeur) ....................................... — 4
3. Description du protocole....................................................................... — 4
3.1 Messages de données................................................................................. — 5
3.2 Messages de contrôle ................................................................................. — 5
3.2.1 Paires attribut/ valeur (AVP)................................................................ — 5
3.2.2 Différents messages de contrôle ....................................................... — 6
4. Signalisation.............................................................................................. — 8
4.1 Établissement de la connexion de contrôle .............................................. — 8
4.2 Établissement de la session L2TP .............................................................. — 8
4.3 Fermeture de la session L2TP..................................................................... — 8
4.4 Fermeture de la connexion de contrôle..................................................... — 8
5. Qualité de Service.................................................................................... — 9
5.1 Numéro de séquence .................................................................................. — 9
5.2 Message de contrôle de type Hello............................................................ — 9
5.3 AVP Differentiated Services ........................................................................ — 9
5.4 Bit de priorité (bit P) .................................................................................... — 10
6. Sécurité dans L2TP.................................................................................. — 10
6.1 AVPs.............................................................................................................. — 10
6.2 L2TP et RADIUS ........................................................................................... — 10
6.3 L2TP et IPsec ................................................................................................ — 10
7. Utilisations de L2TP sur les protocoles de niveau 2...................... — 11
7.1 L2TP over ATM Adaptation Layer 5 (AAL5) ............................................... — 11
7.2 L2TP over Frame Relay................................................................................ — 12
7.3 L2TP sur IP/UDP ........................................................................................... — 12
8. Conclusion ................................................................................................. — 12
9. Annexe : les différentes paires valeur/attribut (AVP) .................... — 13

e protocole de tunneling (processus d’encapsulation permettant une

L connexion point-à-point) de niveau 2 (L2TP, Layer Two Tunnel Protocol) a
été conçu pour encapsuler des paquets PPP (Point-to-Point Protocol) sur les
couches 2 ou 3 (IP) du modèle OSI. Généralement, une connexion de niveau 2
est établie entre un utilisateur et un serveur d’accès au réseau (NAS, Network
Access Server), connexion sur laquelle PPP permet le transport de nombreux
protocoles (IP, IPX, AppleTalk, ...) et ceci sur une liaison point à point. Le NAS

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 1

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

est donc le même point de terminaison pour la connexion de niveau 2 et la

session PPP. L2TP permet de séparer ces deux fonctions en déplaçant le point
de terminaison de la session PPP en un autre point du réseau qu’on appellera
LNS ou L2TP Network Server. Le NAS jouera alors généralement le rôle de LAC
ou L2TP Access Concentrator. Le LAC et le LNS sont les deux extrémités du
tunnel L2TP que l’on crée afin de transporter les sessions PPP jusqu’à un
endroit déterminé du réseau. Seuls le LAC et le LNS ont connaissance du tun-
nel L2TP, le transport des données se fait donc de la manière la plus transpa-
rente possible pour les utilisateurs ou les applications.
L2TP a été développé en se basant sur les protocoles déjà existants
que sont PPTP (Point-to-Point Tunnel Protocol) et L2F (Layer Two Forwarding)
pour n’en garder que les avantages. Ainsi, il devient possible d’interconnecter
des réseaux de même type à travers un réseau ne supportant pas le protocole
utilisé (par exemple, deux réseaux non-IP peuvent communiquer grâce à L2TP
en passant par un réseau IP). Cela permet donc de réduire les coûts en évitant
de devoir se connecter à un NAS lointain, mais plutôt en utilisant une infras-
tructure partagée telle que Frame Relay ou Internet. Par ailleurs, le point de ter-
minaison des sessions PPP ne se situant plus nécessairement au niveau du
NAS, cela permet à un ensemble multilien PPP (PPP Multilink Protocol) de se
terminer au niveau du LNS et donc de récupérer tous ses canaux sur différents
NASes.
L2TP répond également aux attentes en matière de VPNs et de sécurité ; en
effet, utilisé sur IP, L2TP permet de faire du tunneling sur Internet et de créer
des VPNs. Un utilisateur peut ainsi se connecter à son réseau d’entreprise via
un tunnel L2TP (avec authentification) et ainsi récupérer son profil distant. De
plus, il peut se voir attribuer une adresse IP du réseau de son entreprise. Ainsi,
la gestion des adresses IP s’en trouve facilitée et cela évite d’encombrer
inutilement les tables de routage du réseau, le LNS se chargeant d’agréger
toutes ces adresses et d’annoncer les préfixes nécessaires.
En contrepartie, un des principaux inconvénients de L2TP est la taille de son
encapsulation. En effet, le protocole L2TP rajoute un en-tête de 14 octets
maximum, mais si on l’utilise pour faire du tunneling sur Internet, l’empilement
protocolaire nécessaire à ce type de fonctionnement porte à 50 le nombre
d’octets supplémentaires dus aux différentes encapsulations successives
(IP/UDP/L2TP/PPP/IP).

1. Historique Cette architecture particulière a de nombreux intérêts tels que :

— une gestion facilitée des adresses IP ; en permettant à un
utilisateur de conserver la même adresse IP quel que soit son NAS
Le protocole L2TP a été développé par Microsoft et Cisco (ayant généralement le rôle de PAC), du moment qu’il se connecte
Systems, qui, reconnaissant les avantages respectifs de leurs au même PNS ;
solutions de tunneling, ont œuvré pour créer un nouveau protocole — le support de protocoles non IP derrière des réseaux IP,
regroupant le meilleur des deux protocoles que sont PPTP permettant ainsi à deux réseaux IPX ou AppleTalk de communi-
(Point-to-Point Tunnel Protocol, de Microsoft) et L2F (Layer Two quer via un tunnel sur un réseau IP ;
Forwarding, de Cisco). C’est donc de ces deux protocoles, briève- — l’agrégation de canaux ISDN concentrés au niveau du PNS au
ment présentés dans cette partie, qu’est issu le protocole de tun- lieu du NAS ;
neling L2TP. — la transparence vis-à-vis des réseaux commutés, se connectant
au PAC, mais n’ayant aucune connaissance du protocole PPTP.

1.1 Point-to-Point Tunnel Protocol : Remarque : un concentrateur d’accès PPTP (PAC) peut commu-
niquer et donc établir des tunnels avec plusieurs PNS. De même, un ser-
PPTP [RFC2637] veur réseau PPTP (PNS) peut établir une liaison avec de nombreux PAC
et ainsi concentrer le trafic de divers sites en un seul point du réseau.
PPTP [3] est un protocole de tunneling développé par Micro-
soft dans le but de transporter des sessions PPP à travers un 1.1.1 Protocole
réseau IP. Utilisant une architecture client/serveur, il permet de
séparer les fonctions habituelles d’un NAS ou Network Access Le protocole de tunnelisation PPTP repose sur deux éléments
Server (interface avec le réseau téléphonique, terminaison logi- essentiels :
que d’une session PPP, authentification, etc.) entre deux entités — l’établissement d’une connexion de contrôle entre une paire
que sont le PPTP Access Concentrator (PAC) et le PPTP Network PAC-PNS, servant à établir, maintenir et terminer les sessions à
Server (PNS). l’intérieur du tunnel ;

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 2 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

— un tunnel IP entre la même paire PAC-PNS, transportant les

paquets PPP avec une encapsulation GRE (Generic Routing Encap- Utilisateur NAS Home gateway
sulation [RFC2784] cf. référence [5]).
La connexion de contrôle de PPTP s’effectue par une connexion L2F tunnel
TCP sur le port 1723 et sert à gérer les sessions à transporter et le
tunnel. Elle permettra ainsi d’échanger des messages sur l’état des
sessions, les caractéristiques des extrémités du tunnel ou encore Réseau local Internet Réseau
local
de détecter une rupture du tunnel.

Figure 1 – Architecture L2F

1.1.2 Établissement du tunnel et des sessions
La création d’un tunnel PPTP ne s’effectue que s’il y a des données
à transporter du PAC au PNS (ou inversement). Dans un tel cas, la 1.2.2 Établissement du tunnel et des sessions
machine ayant ces données à envoyer demande une ouverture de
connexion TCP vers l’autre bout du tunnel et initie l’ouverture de la Pour établir un tunnel L2F, les deux extrémités du tunnel (le NAS
connexion de contrôle nécessaire à l’établissement du tunnel. Après et le Home Gateway ) communiquent sur la liaison point-à-point
réception d’une réponse positive, la connexion de contrôle est donc établie avec une valeur de MID à 0 (cette valeur est particulière à
établie et peut initier l’ouverture d’une session afin de faire transiter l’établissement du tunnel et ne peut être utilisée pour identifier une
les paquets PPP. L’ouverture de session achevée, les trames PPP sont session L2F). Cela permet d’une part de vérifier que les deux extré-
envoyées à travers le tunnel, complétées par une encapsulation mités du tunnel sont bien configurées pour L2F, d’autre part
GRE. Une ou plusieurs autres sessions PPTP peuvent être ouvertes d’effectuer toute authentification nécessaire (avec un mécanisme
simultanément à travers le même tunnel. Les paquets des différen- d’authentification CHAP par exemple). Une fois ces messages
tes sessions arrivant dans le désordre à l’extrémité réceptrice du envoyés et leurs réponses reçues, le tunnel est actif.
tunnel, c’est l’identifiant de session contenu dans l’en-tête GRE qui Un utilisateur distant demande une connexion virtuelle, le NAS
permet au récepteur de reconstituer correctement les messages et recevant l’appel transmet donc la demande au Home Gateway en
de les router vers la bonne destination. encapsulant le paquet reçu et en attribuant un MID au paquet (et à
Une fois toutes les sessions terminées dans un tunnel, c’est-à-dire tous ceux qui suivront pour cette session). Le Home Gateway
quand tous les paquets ont été transmis et qu’il n’y en a plus en effectue une authentification et renvoie un message acceptant la
attente à l’une des extrémités du tunnel, la connexion de contrôle demande au NAS.
et le tunnel sont arrêtés après la fermeture de la dernière session. Tout le trafic envoyé par l’utilisateur est maintenant autorisé à
circuler sur le tunnel L2F ; le Home Gateway recevant les paquets
L2F, retire les encapsulations [en-têtes et sommes de contrôle
1.2 Layer 2 Forwarding : L2F [RFC2341] (checksums) éventuels] et les expédie à leur destination.

Cisco Systems a mis au point le protocole L2F [2] à la fin des Remarque : des messages de gestion du tunnel et des données
années 90 afin de permettre à un nouveau type d’applications sont également envoyés à travers le tunnel, indiquant par exemple un
d’être utilisé sur le réseau Internet. Ces applications sont celles qui message de données invalide, ou demandant le nom de l’autre
utilisent un adressage de machine de type différent de celui de extrémité du tunnel, ou encore un message de type Echo afin de
l’Internet (adresses IP « privées », IPX ou AppleTalk ). vérifier la présence de l’autre extrémité.
L’intérêt d’un tel protocole est qu’il permet aux utilisateurs Une session s’arrête lorsqu’une des extrémités du tunnel reconnaît
d’Internet l’accès à des ressources encore plus nombreuses et dans un paquet PPP une fin de session PPP ; elle entreprend alors
diverses. De plus, le support des protocoles autres que IP se fait de de mettre fin à la session L2F.
manière fiable et sécurisée et permet d’agrandir la communauté
Internet à des réseaux jusqu’alors incompatibles.
L2F est l’un des précurseurs en matière de protocole d’accès
pour les protocoles non IP.
2. Terminologie
1.2.1 Protocole
Le protocole L2TP tirant partie des protocoles PPTP et L2F, il
Le protocole L2F fonctionne comme un service virtuel de utilise un vocabulaire similaire à celui de ces deux protocoles à
connexion ; c’est-à-dire que lorsqu’un utilisateur veut se connecter, quelques différences près. La compréhension des termes utilisés
le NAS de son fournisseur d’accès Internet vérifie si l’utilisateur a pour L2TP est donc très importante et nécessaire à la compré-
besoin d’un service de connexion virtuel et dans un tel cas, créé un hension du protocole.
tunnel vers le serveur d’accès désiré (appelé Home Gateway ). C’est
ce serveur qui effectuera les fonctions classiques du NAS, à savoir,
l’authentification, l’autorisation, l’accounting et l’adressage de l’uti- 2.1 L2TP Access Concentrator
lisateur.
(concentrateur d’accès L2TP)
Entre le NAS de l’ISP et le Home Gateway, les données sont
transmises à travers un tunnel L2F (voir figure 1).
Le concentrateur d’accès L2TP ou LAC est l’équipement terminal
Le protocole L2F est caractérisé par deux points importants : du tunnel L2TP qui est en relation avec l’utilisateur distant.
— l’encapsulation des paquets PPP ; C’est-à-dire que c’est lui qui reçoit les paquets PPP de l’utilisateur,
— la gestion des tunnels L2F et des MIDs (Multiplex IDentifiers : les encapsule et les envoie sur le tunnel vers l’autre extrémité (le
un MID est associé à une session particulière d’un tunnel). LNS) ; de même, c’est lui qui reçoit des paquets encapsulés depuis
le LNS à travers le tunnel, retire l’encapsulation et les expédie vers
Contrairement à PPTP, l’établissement d’un tunnel L2F se fait sur
l’utilisateur distant (figure 2).
UDP et l’encapsulation L2F se compose d’un en-tête et d’un
checksum L2F (optionnel) qui sont placés respectivement au début En général, c’est le serveur d’accès réseau (NAS) qui joue le rôle
et à la fin d’un paquet de données PPP ou SLIP. de LAC.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 3

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

donc constitué de l’attribut Host-Name et de la valeur représentant

Utilisateur IP/ATM/
le nom du LAC ou du LNS). Plusieurs AVPs sont utilisés pour
distant PSTN/ISDN LAC Frame relay LNS constituer les différents messages de contrôle et ainsi permettre la
gestion des tunnels et sessions L2TP.
Les AVPs seront abordés plus en détail dans le paragraphe 3.2.1.

Tunnel L2TP Réseau

local
Session PPP 3. Description du protocole
Figure 2 – Connexion utilisant un tunnel L2TP
Le protocole L2TP permet le transport des sessions PPP à
travers un tunnel sur des liaisons de niveau 2 (ATM/Frame
Relay) ou 3 (IP).
2.2 LNS : L2TP Network Server
(serveur réseau L2TP) Pour qu’une session PPP puisse être transportée jusqu’à un LNS,
l’une des deux extrémités (par exemple le LAC) doit demander la
Le serveur réseau L2TP ou LNS est la seconde extrémité du
création d’un tunnel. L’autre extrémité (le LNS) envoie alors une
tunnel L2TP. C’est lui qui communique avec le LAC à travers le
confirmation de la création de tunnel. Le LAC répond en envoyant
tunnel. De même que le LAC, c’est lui qui ajoute, respectivement
aussi une confirmation de création de tunnel. La connexion de
retire, l’encapsulation L2TP pour envoyer les messages vers le LAC
contrôle est donc initiée sur le tunnel. On établit ensuite une
et l’utilisateur distant, respectivement vers le réseau local. Ce qui
session L2TP grâce à un envoi de messages de contrôle similaires
différencie le LNS du LAC est que le LNS est le point de termi-
(demande, 1re confirmation, 2nde confirmation) sur le canal de
naison logique de la session PPP initié par l’utilisateur distant.
contrôle. Les données peuvent alors être envoyées via le tunnel
La figure 2 résume cela. L2TP. Régulièrement, le protocole envoie des messages de
contrôle, qui doivent être acquittés afin de s’assurer de la bonne
communication à travers le tunnel.
2.3 Tunnel L2TP Le protocole L2TP met en œuvre deux types de messages :
— les messages de données qui contiennent les trames PPP
Un tunnel L2TP est une connexion établie entre un doublet encapsulées à transporter sur le tunnel ;
LAC-LNS. Il comprend une connexion de contrôle et zéro ou plus — les messages de contrôle qui gèrent l’établissement, la
session(s) L2TP (sachant qu’en cas d’absence de session dans le continuité et la fermeture du tunnel et des sessions.
tunnel, ce dernier sera désactivé). C’est à travers le tunnel L2TP
que sont envoyés les paquets PPP encapsulés et les messages de Ces deux types de messages sont envoyés à travers le tunnel sur
contrôle servant à la gestion du tunnel et des sessions. deux canaux différents ; les messages de contrôle sont envoyés sur
un canal fiable, qui assure la bonne réception d’un paquet, tandis
que le canal utilisé par les paquets de données n’effectue aucune
retransmission en cas de pertes de paquets.
2.4 Session L2TP
La figure 3 représente les canaux de transmission du protocole
Une session L2TP est créée à l’intérieur d’un tunnel L2TP et ainsi que les messages y circulant.
correspond à une session PPP particulière, initiée par l’utilisateur Les trames PPP sont encapsulées avec un en-tête L2TP et
distant vers le LNS. Il peut donc exister plusieurs sessions L2TP à envoyées sur un canal L2TP, non fiable, reposant sur Frame Relay,
l’intérieur d’un tunnel L2TP ; en fait, il en existe autant que la ATM ou encore UDP. Les messages de contrôle sont envoyés sur
somme de toutes les sessions PPP de chaque utilisateur distant un canal L2TP fiable reposant sur la même couche de transport.
connecté au LNS.
Les deux types de messages L2TP (de données et de contrôle)
ont un en-tête L2TP identique, représenté sur la figure 4 ; seules
les options incluses ou pas, selon le type de message, peuvent
2.5 Connexion de contrôle varier.
Le tableau 1 donne la signification des différents bits et champs
Elle est l’un des éléments les plus importants du protocole L2TP. de cet en-tête ainsi que leur valeur selon le type de messages
La connexion de contrôle est établie entre le LAC et le LNS avant lorsque cela est possible.
même le tunnel dans un but de gestion de la communication entre
le concentrateur et le serveur. C’est elle qui gère l’établissement et
la destruction du tunnel et des sessions mais aussi leur bon
fonctionnement. Elle opère grâce à des messages dits de contrôle
qui sont envoyés régulièrement entre le LAC et le LNS et qui
contiennent de nombreuses informations sur le tunnel et les Trames PPP
sessions en cours.
En-têtes de Messages de
données L2TP contrôle L2TP

2.6 AVP : Attribute Value Pair Canal de

données L2TP
Canal de
contrôle L2TP
(paire attribut-valeur) (non fiable) (fiable)

L’AVP fait partie des messages L2TP envoyés. Il s’agit en fait d’infor- Couche de transport (UDP, Frame Relay, ATM,...)
mations contenues sous la forme d’un doublet attribut-valeur. Le
message contient donc un attribut particulier et sa valeur (par exem-
ple, un AVP contient le nom d’une extrémité du tunnel, cet AVP sera Figure 3 – Les canaux de transmission L2TP

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 4 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

(0)

Tableau 1 – Détail de l’en-tête L2TP

Champ ou bit Signification Message de données Message de contrôle
T (Type bit) Indique le type de message. 0 1
L (Length bit) Indique si le champ Length est présent par la valeur 1. Optionnel 1
x Ces bits sont réservés pour des extensions futures et doivent être positionnés à 0.
S (Sequence bit) Indique si les champs Ns et Nr sont présents. Optionnel 1
O (Offset bit) Indique si le champ Offset Size est présent. Optionnel 0
P (Priority bit) Si le bit P est à 1, le message de données devrait être traité de façon Optionnel 0
privilégiée.
Ver (Version) Le champ Ver indique la version du protocole utilisée. Ce champ doit prendre la valeur 2 pour indiquer l’utilisation de
L2TP. La valeur 1 est utilisée pour détecter des paquets L2F.
Length Ce champ contient la longueur totale du message, en octets.
Tunnel ID Indique l’identifiant de tunnel pour la connexion de contrôle. Le LAC et le LNS attribuent chacun un Tunnel ID à un
tunnel ; c’est-à-dire qu’un même tunnel a de fortes chances d’avoir deux Tunnel ID, un pour le LAC et un pour le LNS.
Session ID Indique l’identifiant de session dans le tunnel spécifié par le champ Tunnel ID. De même que le Tunnel ID, la session se
voit attribuée une valeur de Session ID par le LAC et une autre, par le LNS.
Ns Ce champ indique le numéro de séquence pour ce message de données ou de contrôle. L’utilisation des numéros de
séquence sera détaillée dans le § 5.1.
Nr Le champ Nr indique le numéro de séquence attendu pour le prochain message de contrôle ; ce champ est ignoré s’il est
présent dans un message de données.
Offset Size Ce champ spécifie le nombre d’octets contenu dans le champ Offset Padding, c’est-à-dire le nombre d’octets qu’il y a
entre la fin de l’en-tête L2TP et le début des données PPP.
Offset Padding Le contenu de ce champ n’est pour l’instant pas défini. Il pourrait servir à aligner les données sur une certaine longueur
dans un but d’amélioration des performances.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
T L x x S x OP x x x x Ver Length (option)
MH rsvd Length Vendor ID
Tunnel ID Session ID
Attribute Type Attribute Value...
Ns (option) Nr (option)
(jusqu'à atteindre la longueur Length)...
Offset Size (option) Offset Pad... (option)

Figure 4 – En-tête d’un paquet L2TP Figure 5 – Format d’une paire attribut-valeur (AVP)

3.1 Messages de données 3.2.1 Paires attribut/ valeur (AVP)

Dans un but d’interopérabilité et d’extensions futures, le format
Les trames PPP, reçues au niveau du LAC ou du LNS, sont
des AVPs a été uniformisé. La figure 5 représente les octets qui
délestées des couches inférieures (CRC, Link Framing, Trans-
sont rajoutés après l’en-tête L2TP pour chaque AVP.
parency Bytes ) et encapsulées avec cet en-tête L2TP, ce qui rajoute
entre 6 (en-tête L2TP sans aucune option) et 14 octets (avec toutes Le bit M (Mandatory ) indique le caractère obligatoire de l’AVP, et
les options). Les messages de données, ainsi constitués, sont influe sur le comportement du LAC ou du LNS recevant un tel AVP.
envoyés à travers le tunnel approprié jusqu’à l’autre extrémité qui Lors de la réception d’un AVP inconnu, si le bit M est à 1, la session
retire l’encapsulation L2TP et traite la trame PPP comme si elle à laquelle est associé le message doit être fermée. Si le message
venait d’arriver sur une interface PPP locale. concerne un tunnel et que le bit M est positionné à 1, le tunnel doit
L’encapsulation L2TP pour les messages de données ne prévoit être fermé. Si le bit M prend la valeur 0 dans un AVP inconnu, celui-ci
aucune forme de contrôle d’intégrité, cela doit donc être effectué est ignoré et le traitement continue.
par les protocoles encapsulés. Le bit H (Hidden ) indique un masquage des données du champ
Les messages de données peuvent être numérotés (champs Ns Attribute Value, évitant à des données confidentielles (nom d’uti-
et Nr ), mais L2TP ne gère pas la retransmission d’un paquet perdu. lisateur, mot de passe) de circuler clairement.
Le champ Length codé sur 10 bits, indique la taille totale de
l’AVP en octets, comprenant tous les drapeaux et champs relatifs
3.2 Messages de contrôle à l’AVP. La figure 5 montre qu’un AVP a donc une taille minimale
de 6 octets (si le champ Attribute Value est vide).
Les messages de contrôle sont constitués de l’en-tête L2TP, suivi Le Vendor ID (2 octets) est un numéro correspondant à l’entre-
d’une succession d’AVPs qui contiennent de nombreuses infor- prise qui a créé l’AVP. Les différentes valeurs du champ Vendor ID
mations permettant la gestion du tunnel et des sessions. sont définies dans le RFC1700 (cf. référence [1]). (0)

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 5

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

— L’AVP Called Number indique le numéro de téléphone du

Tableau 2 – Résumé du contenu d’un AVP destinataire du message ;
Bit M (Mandatory ) Bit de contrôle indiquant un AVP obligatoire. — (Tx) Connect Speed indique la vitesse de connexion pour le
service L2TP.
Bit H (Hidden ) Permet de crypter les données contenues
dans l’AVP. Les AVPs indiquant des messages d’erreur sont au nombre de 3 :
— l’AVP Result Code précise la raison de la fin d’une session ou
rsvd Quatre bits réservés pour des extensions
futures. d’une connexion de contrôle ;
— l’AVP Call Errors permet au LAC d’indiquer au LNS que des
Length Taille de l’AVP en octets. erreurs sont survenues ;
Vendor ID Ce champ contient le créateur de l’AVP — l’AVP ACCM est envoyé au LAC pour indiquer la valeur de
transporté. l’ACCM (Asynchronous Control Character Map pour LCP) négociée
par le LNS.
Attribute Type Le type de l’AVP.
Attribute Value La valeur de l’AVP. 3.2.2 Différents messages de contrôle
Il y a quatorze types de messages de contrôle, ayant chacun un
Le champ Attribute Type (2 octets) indique quel attribut est rôle particulier, que nous pouvons classer comme indiqué dans le
contenu dans l’AVP. La liste des attributs et leur signification sont tableau 3. (0)
données dans l’annexe (§ 9). Tous ces messages jouent un rôle particulier dans l’établis-
Enfin, le champ Attribute Value contient la valeur de l’attribut sement et la gestion des tunnels et sessions L2TP. Les procédures
indiqué. Sa longueur est variable car elle dépend du type d’attribut. mettant en jeu ces messages étant décrites dans le paragraphe 4,
seule une brève explication sur le rôle des messages et sur leur
On peut classer les AVPs en plusieurs catégories en fonction de contenu est donnée ici.
leur utilité :
— ceux qui servent à la gestion de la connexion de contrôle ; ■ Message Start-Control-Connection-Request (SCCRQ)
— ceux qui gèrent les appels (sessions) ; C’est le premier message envoyé entre un LAC et un LNS pour
— ceux qui indiquent des erreurs. commencer la procédure d’établissement de tunnel L2TP. Il peut être
Nota : ne sont décrits que les AVPs obligatoires pour les messages de contrôle et définis envoyé par n’importe laquelle des extrémités (LAC ou LNS). Ce mes-
par l’IETF dans le RFC2661 (cf. référence [4]), standardisant le protocole L2TP. sage doit contenir un minimum d’information pour initier la
L’annexe (§ 9) regroupe les AVPs par catégorie dans des tableaux, indique leurs noms, connexion. Les renseignements nécessaires sont les AVPs Message
spécifie la valeur du champ Attribute Type, explique leur utilité et indique dans quels Type (prenant la valeur 1 pour annoncer un message SCCRQ), Pro-
messages de contrôle ils peuvent être présents (cf. tableaux 5, 6, 7 et 8 p. 13 et 14).
tocol Version, Host Name, Framing Capabilities, Assigned Tunnel ID.
Il y a deux AVPs particuliers qui peuvent se retrouver dans Ces AVPs ont été définis précédemment (cf. § 3.2.1).
n’importe quel message de contrôle : Par ailleurs, d’autres AVPs peuvent être envoyés dans ce
— l’AVP Message Type qui indique le type du message L2TP. Il message afin de donner de plus amples informations à l’extrémité
est obligatoire dans tous les messages de contrôle et doit être le du tunnel. Par exemple, les AVPs Bearer capabilities, Receive
premier AVP d’un message de contrôle ; Window Size, Challenge (en cas de demande d’authentification),
— l’AVP Random Vector qui sert à crypter la valeur du champ Tie Breaker, Firmware Revision, Vendor Name qui sont définis
Attribute Value de tout AVP ayant le bit H à la valeur 1 (voir dans l’annexe (§ 9).
figure 5, tableau 2 et § 6.1).
■ Message Start-Control-Connection-Reply (SCCRP)
Les AVPs servant à la gestion de la connexion de contrôle sont :
L2TP envoie ce message en réponse au message SCCRQ et
— Protocol Version : contient la version du protocole L2TP uti- signifie que ce dernier a bien été reçu et accepté. L’établissement
lisée par l’expéditeur du message ; du tunnel peut continuer.
— Framing Capabilities : donne des informations sur le type de
trames émises ou reçues par l’expéditeur de l’AVP ; Les AVPs devant figurer dans ce message de contrôle sont les
— Host Name : contient le nom de l’émetteur du message ; mêmes que ceux du message SCCRQ avec des valeurs différentes.
— Assigned Tunnel ID : indique le numéro d’identification du Il s’agit donc des AVPs MessageType (prenant la valeur 2 pour annon-
tunnel attribué par l’expéditeur du message. Cela permet, s’il cer un message SCCRP), Protocol Version, Host Name, Framing
existe plusieurs tunnels sur une même paire LAC-LNS, de savoir à Capabilities, Assigned Tunnel ID. Les mêmes AVPs que pour le mes-
quel tunnel un message appartient. sage SCCRQ peuvent également être ajoutés pour fournir de plus
amples renseignements : Bearer capabilities, Receive Window Size,
Pour la gestion des appels, cela diffère si l’appel est initié par le Challenge (en cas de demande d’authentification), Challenge Res-
client distant ou par le serveur. La distinction se fait par le type de ponse, Firmware Revision, Vendor Name.
message envoyé (message de type Outgoing ou Incoming ) et est
indiquée dans l’annexe (§ 9). ■ Message Start-Control-Connection-Connected (SCCCN)
— L’AVP Assigned Session ID indique le numéro d’identification Il s’agit de la réponse à un message SCCRQ. Il complète la
attribué par l’expéditeur de l’AVP pour la session L2TP. On peut procédure de création de tunnel. Ce message reçu, le tunnel est
donc connaître la session à laquelle un message appartient ; créé par les deux extrémités. Le seul AVP obligatoire est l’AVP
— Call Serial Number correspond à un identifiant attribué à la Message Type prenant alors la valeur 3. Il peut également contenir
session PPP par le LAC ou le LNS ; une réponse à une demande d’authentification avec un AVP de
— L’attribut Minimum BPS représente la vitesse de connexion type Challenge Response.
minimale requise pour la session PPP ; ■ Message Stop-Control-Connection-Notification (StopCCN)
— L’attribut Maximum BPS représente la vitesse de connexion
Un message SCCCN est envoyé par une extrémité du tunnel
maximale autorisée pour la session PPP ;
pour informer l’autre extrémité que le tunnel est en cours de fer-
— Bearer Type précise si le canal de transmission est analogique meture et que la connexion de contrôle devrait être arrêtée égale-
ou digital ; ment. Un tel message implique nécessairement que toutes les
— Framing Type spécifie si l’envoi des trames se fait de manière sessions encore actives dans le tunnel soient arrêtées. Cela se fait
synchrone ou asynchrone ; de manière implicite, sans aucune forme de signalisation.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 6 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

Tableau 3 – Les messages de contrôle

Catégorie Nom du message Abréviation Valeur de l’AVP message-type
Start-Control-Connection-Request SCCRQ 1
Start-Control-Connection-Reply SCCRP 2
Gestion de la connexion de contrôle Start-Control-Connection-Connected SCCCN 3
Stop-Control-Connection-Notification StopCCN 4
Hello HELLO 6
Outgoing-Call-Request OCRQ 7
Outgoing-Call-Reply OCRP 8
Outgoing-Call-Connected OCCN 9
Gestion des sessions Incoming-Call-Request ICRQ 10
Incoming-Call-Reply ICRP 11
Incoming-Call-Connected ICCN 12
Call-Disconnect-Notification CDN 14
Rapport d’erreur WAN-Error-Notify WEN 15
Contrôle de session PPP Set-Link-Info SLI 16

Ce message contient l’AVP Message Type prenant la valeur 4, La valeur de l’AVP Message Type pour ce message est 9 ; les
l’AVP Assigned Tunnel ID permettant d’identifier le tunnel auquel AVPs Framing Type ainsi que (Tx) Connect Speed sont également
appartient le message, et donc le tunnel à fermer, et aussi l’AVP présents dans ce message ; ils indiquent respectivement un envoi
Result Code qui indique la raison de la fermeture du tunnel. synchrone ou asynchrone des trames et la vitesse de connexion du
côté du LNS. Peuvent également être envoyés dans un message
■ Message Hello (HELLO) OCCN les AVPs (Rx) Connect Speed (indiquant la vitesse de
Le message Hello est un message de contrôle permettant de connexion entre le LAC et l’utilisateur distant) et Sequencing
vérifier que la communication entre le LAC et le LNS est toujours Required (précisant au LNS que les numéros de séquences doivent
possible. Il est envoyé si aucune activité particulière n’est détectée être utilisés pour tous les messages de données, c’est-à-dire que
dans le tunnel (ni données, ni messages de contrôle) par n’importe les champs Ns et Nr doivent être remplis dans l’en-tête L2TP).
quelle extrémité du tunnel. Il attend un message ZLB (Zero-Length
Body ) en guise d’acquittement. ■ Message Incoming-Call-Request (ICRQ)
Le seul AVP contenu dans un message Hello est l’AVP Message Ce message est envoyé par le LAC vers le LNS pour indiquer que
Type qui prend alors la valeur 6. l’utilisateur distant veut initier une session PPP vers le LNS. De
même que le message SCCRQ pour l’établissement d’un tunnel, le
■ Message Outgoing-Call-Request (OCRQ) message ICRQ est le premier message d’une série de trois pour
l’établissement d’une session L2TP à travers le tunnel.
Ce message est envoyé par le LNS vers le LAC pour lui signaler
qu’une connexion PPP vers l’utilisateur distant est demandée. De Il doit contenir les informations relatives au type du message (AVP
même que le message SCCRQ pour l’établissement d’un tunnel, le Message Type de valeur 10), au numéro d’identification de la session
message OCRQ est le premier message d’une série de trois pour choisi par le LAC (AVP Assigned Session ID ) et au numéro d’iden-
l’établissement d’une session L2TP à travers le tunnel. tification de l’appel choisi par le LAC (AVP Call Serial Number ). On
peut également y trouver les APVs Bearer Type, Physical Channel
Ce message doit contenir les AVP Message Type (valeur : 7), Assi- Address, Calling Number, Called Number et Sub-Address.
gned Session ID (qui indique le numéro d’identification de la ses-
sion, choisi par le LNS), Call Serial Number, Minimum BPS, ■ Message Incoming-Call-Reply (ICRP)
Maximum BPS, Bearer Type, Framing Type, Called Number.
Le message ICRP est envoyé en réponse au message ICRQ, donc
■ Message Outgoing-Call-Reply (OCRP) envoyé par le LNS. Il indique que la demande de session a bien été
reçue et prise en compte ; l’établissement de la session peut
Le message OCRP est envoyé en réponse au message OCRQ ; continuer.
donc envoyé par le LAC. Cela signifie que le LAC accepte la
demande de session, l’établissement de la session peut donc La valeur 11 est donnéé à l’AVP Message Type dans ce message,
continuer. Ce message (Message Type valant 8) précise le numéro qui doit aussi contenir le numéro d’identification de session choisi
d’identification de la session choisi par le LAC (AVP Assigned par le LNS (Assigned Session ID ).
Session ID).
■ Message Incoming-Call-Connected (ICCN)
■ Message Outgoing-Call-Connected (OCCN) C’est le dernier des trois messages pour l’établissement de
C’est le dernier des trois messages spécifiques pour l’établis- la session. Il est envoyé par le LAC vers le LNS pour indiquer que
sement de la session initiée par le LNS. Il est envoyé par le LAC, la session est désormais établie à travers le tunnel et que la ses-
une fois l’appel établi entre le LNS et l’utilisateur distant, pour sion PPP provenant de l’utilisateur distant va pouvoir être transpor-
indiquer que la session est désormais active à travers le tunnel et tée à travers le tunnel.
que la session PPP provenant de l’extérieur va pouvoir être La valeur de l’AVP Message Type est 12 pour l’ICCN. Le message
transportée à travers le tunnel puis jusqu’à l’utilisateur distant. contient également les AVPs (Tx) Connect Speed et Framing Type.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 7

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

■ Message Call-Disconnect-Notify (CDN) 4.2 Établissement de la session L2TP

Ce message est utilisé pour la déconnexion d’une session.
Envoyé indifféremment par le LAC ou le LNS, il indique quelle Contrairement à la connexion de contrôle, le processus d’ouver-
session arrêter par l’AVP Assigned Session ID et la raison de cette ture de session L2TP est dépendant de l’extrémité qui initie la
déconnexion par l’AVP Result Code. L’AVP Message Type prend la session.
valeur 14.
■ Premier cas : le LAC reçoit un appel pour le réseau local distant
■ Message WAN-Error-Notify (WEN) Le LAC reçoit donc l’appel et envoie un message d’ouverture de
Envoyé par le LAC vers le LNS, ce message (AVP Message Type session vers le LNS : un message ICRQ (Incoming-Call-Request )
de valeur 15) indique qu’une erreur est survenue au niveau de contenant un Session ID et un numéro d’identification de l’appel
l’interface du LAC supportant la session PPP et en précise le type choisis par le LAC, ainsi que le type de l’appel (analogique ou
(AVP Call Errors ). digital). Le LNS accepte l’appel en envoyant un message ICRP
(Incoming-Call-Reply ). Après avoir essayé, avec succès, de
■ Message Set-Link-Info (SLI) connecter l’appel, le LAC complète l’ouverture de la session L2TP
avec un message ICCN (Incoming-Call-Connected ).
Ce message (AVP Message Type de valeur 16) est envoyé par le
serveur L2TP vers le concentrateur d’accès pour indiquer des L’établissement d’une session par le LAC est schématisé sur la
options sur le lien utilisé pour le transport (AVP ACCM). figure 6b.

■ Second cas : le LNS reçoit un appel pour l’utilisateur distant

Le LNS initie une ouverture de session L2TP vers le LAC en
4. Signalisation envoyant un message OCRQ (Outgoing-Call-Request ) et attend un
message OCRP (Outgoing-Call-Reply ) en réponse. Le LAC envoie ce
message pour autoriser l’ouverture de la session et essaye de
Avant de transporter des trames PPP à travers un tunnel, le connecter l’appel au LNS. Cet appel établi, le LAC envoie finalement
protocole L2TP doit s’assurer de deux points importants : un message OCCN (Outgoing-Call-Connected ) pour informer que la
— l’établissement d’une connexion de contrôle entre le LAC et le session est bien ouverte et active. Si le LNS n’a aucun message
LNS permettant la gestion du tunnel et des sessions à l’intérieur ; particulier à envoyer au LAC, il répond par un message ZLB. Ce pro-
— l’établissement de la session de transport à l’intérieur du cédé est schématisé sur la figure 7b, sur laquelle on peut remarquer
tunnel. que le LNS n’envoie pas de message ZLB après la création de la
connexion de contrôle (phase a ) car il doit initier une session et a
L’établissement de la connexion de contrôle est la première donc un nouveau message à transmettre. Le message d’ouverture
étape à effectuer avant de pouvoir initier une ou plusieurs sessions de session OCRQ sert donc également d’accusé de réception du
L2TP. Elle correspond à l’établissement du tunnel L2TP entre les message SCCCN reçu depuis le LAC.
deux entités que sont le LAC et le LNS.
Un tunnel L2TP peut contenir plusieurs sessions L2TP ; de
même, il peut exister plusieurs tunnels différents entre un LAC et 4.3 Fermeture de la session L2TP
un LNS.
Une fois toutes les données envoyées (figure 6c ), une des extré-
mités peut demander la fermeture de la session. Le LAC (ou le LNS)
envoie alors un message Call-Disconnect-Notify (CDN), demandant
4.1 Établissement de la connexion cette fermeture et indiquant également la raison de cette
de contrôle déconnexion (fin de la session ou erreur). La seconde extrémité du
tunnel accuse réception du message et de la fin de la session en
La connexion de contrôle est initiée par l’une des deux extrémités renvoyant un message ZLB (voir figure 6d ). Cette fin de session
du tunnel (LAC ou LNS) et débute toujours par l’envoi d’un message entraîne de la part des deux extrémités une libération de toutes les
SCCRQ (Start-Control-Connection-Request ). Nous allons supposer ressources utilisées pour cette session.
que c’est le LAC qui initie la demande de connexion de contrôle, Lorsque la dernière session du tunnel est fermée, et que le tun-
c’est donc lui qui envoie le message SCCRQ. À cela, le LNS répond nel ne supporte donc plus aucune session, il doit être également
par un message SCCRP (Start-Control-Connection-Reply ) afin détruit. Il y a donc fermeture de la connexion de contrôle.
d’accuser réception de la demande de connexion, de la valider et
de continuer le processus. Le LAC, ayant reçu le message SCCRP,
renvoie un message de contrôle de type SCCCN (Start-Control-Con- 4.4 Fermeture de la connexion de contrôle
nection- Connected ) afin de confirmer l’établissement de la
connexion de contrôle. Si le LNS n’a aucun message particulier à La fermeture de la connexion de contrôle intervient en cas de
envoyer au LAC, il répond par un message de type ZLB ACK fermeture de la dernière session transportée par le tunnel, de perte
(Zero-Length-Body Acknowledgement ) en guise d’accusé de récep- de connexion entre le LAC et le LNS ou encore dans le cas d’erreur
tion, sinon, il commence l’émission de paquets d’ouverture grave dans les messages de contrôle.
de session. La procédure d’ouverture de tunnel est représentée sur L’entité demandant la fermeture du tunnel envoie un message
la figure 6a. StopCCN (Stop Control Connexion Notify ) indiquant la raison de
L’échange de ces messages permet notamment l’identification cette fermeture par l’AVP Result Code. L’extrémité recevant ce
(AVP Host Name ), l’authentification (optionnelle) des extrémités du message renvoie un message ZLB pour confirmer la fermeture du
tunnel grâce aux AVPs Challenge (messages SCCRQ et SCCRP) et tunnel (voir figure 6e ). Toutes les ressources utilisées par les deux
Challenge Response (messages SCCRP et SCCCN), la connaissance extrémités du tunnel pour sa gestion et celles des sessions sont
de la version de L2TP utilisée par le LAC et le LNS (AVP Protocol alors libérées.
Version ), ou encore des possibilités techniques des deux extré- Remarque : une demande de fermeture de tunnel peut tout à fait
mités (AVPs Framing Capabilities, Bearer Capabilities, Receive être envoyée même s’il existe encore des sessions à l’intérieur du tun-
Window Size ). nel. Dans ce cas, toutes les sessions sont fermées implicitement,
La procédure et les messages auraient été similaires si le LNS c’est-à-dire sans envoyer de message de demande de fermeture de
avait initié la connexion de contrôle. session.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 8 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

quant à lui, indique la valeur du numéro de séquence attendu dans

le prochain message ; il s’agit donc de la valeur du champ Ns du
LAC LNS dernier message reçu, incrémentée de 1.
SCCRQ
Le premier message de contrôle envoyé par une des deux
SCCRP
a établissement extrémités est envoyé avec une valeur de Ns égale à 0. L’extrémité
SCCCN d'un tunnel réceptrice envoie une réponse en incrémentant cette valeur de 1 et
ZLB en la plaçant dans le champ Nr. Elle initie elle aussi son champ Ns
à 0. Chaque extrémité du tunnel gère donc son propre compteur de
ICRQ numéro de séquence indépendamment de l’autre extrémité. Il
ICRP s’effectue ainsi un contrôle implicite des messages par vérification
établissement du numéro de séquence reçu avec celui attendu. Cela permet donc
ICCN b
d'une session de repérer la perte d’un ou plusieurs messages de contrôle et
ZLB d’effectuer leur retransmission sur le tunnel.
données La connexion de contrôle étant un canal de transmission fiable
(les pertes de paquets entraînent les réémissions), tous les messages
données
envoi des de contrôle doivent contenir les champs Ns et Nr dans l’en-tête L2TP.
données c Les messages de données peuvent éventuellement avoir ces champs
données
données présents dans leur en-tête L2TP, mais il ne sera fait aucune retrans-
mission en cas de pertes de paquets ; les numéros de séquence dans
CDN les messages de données peuvent servir à détecter la perte de
fermeture
d d'une session paquets, ce qui peut être utile pour établir des statistiques sur les
ZLB
pertes de paquet et sur la fiabilité des différents liens.
StopCCN
fermeture
ZLB e
d'un tunnel
5.2 Message de contrôle de type Hello
Le message Hello (Message Type 6) est un message de contrôle
Figure 6 – Mécanisme de création de tunnel et de sessions permettant de s’assurer que la connexion de contrôle entre le LAC
(appel intérieur) et le LNS fonctionne toujours correctement. Par l’envoi d’un
message Hello sur la connexion de contrôle et par la réception du
message attendu (en l’occurrence un message ZLB), ce mécanisme
permet de vérifier que si une extrémité ne reçoit aucun message
depuis un tunnel, cela n’est dû qu’à un manque d’activité de la part
LAC LNS des deux extrémités (envoi/réception de messages de données et
SCCRQ de contrôle) et non pas à une rupture dudit tunnel.
SCCRP a établissement Après une certaine période pendant laquelle une extrémité n’a
d'un tunnel reçu aucun message de données ni de contrôle (60 secondes par
SCCCN
défaut), elle envoie un message Hello. Elle attend ensuite la réponse
de l’autre extrémité du tunnel. Si le message ZLB arrive, la
OCRQ
connexion de contrôle est toujours présente et fonctionne correcte-
OCRP établissement ment. Le tunnel est maintenu. En revanche, si aucun message n’est
b reçu après plusieurs tentatives, l’extrémité du tunnel estime que le
OCCN d'une session
tunnel est cassé et que la connexion de contrôle de même que les
ZLB
sessions à l’intérieur du tunnel doivent être supprimées.
Ce mécanisme, implémenté sur les deux extrémités du tunnel,
assure que ces dernières détectent cette chute de tunnel ; car le LAC
Figure 7 – Mécanisme de création de tunnel et de sessions (tout comme le LNS), après une certaine période sans réception de
(appel extérieur) message, enverra un message Hello pour tester la connexion avec
l’autre extrémité. L’un autant que l’autre, ne recevant aucune
réponse, pourra alors clore les sessions encore présentes dans le
tunnel puis arrêter le tunnel lui-même.
Ce mécanisme permet donc de repérer relativement rapidement
5. Qualité de Service une interruption du tunnel à la fois par le LAC et par le LNS. On
s’assure ainsi qu’il ne reste pas une des deux extrémités qui reste
Comme le montre la figure 3, il y a deux canaux de transmission dans un état particulier à attendre des messages sur un tunnel qui
pour les messages L2TP : l’un fiable, l’autre non. Contrairement aux n’existe plus.
messages de données, les messages de contrôle sont envoyés sur
le canal fiable car il est nécessaire que ces messages soient bien
reçus par l’autre extrémité. C’est grâce à un mécanisme d’acquitte- 5.3 AVP Differentiated Services
ment implicite par numéro de séquence que cela est possible.
L2TP peut aussi se servir de plusieurs AVPs pour assurer une
meilleure qualité de service. Ces AVPs, définis dans le RFC3308
5.1 Numéro de séquence (cf. référence [6]) permettent la mise en place de services différen-
ciés (Differentiated Services ) pour la connexion de contrôle et pour
En effet, il existe deux champs dans l’en-tête L2TP (voir figure 4, les sessions.
les champs Ns et Nr qui servent à identifier la séquence des Ces AVPs sont décrits dans le tableau 4. L’un, l’AVP CCDS, est uti-
messages de contrôle). Le champ Ns codé sur 2 octets indique la lisé pour la connexion de contrôle, l’autre, l’AVP SDS, initie Diff
valeur du numéro de séquence du message envoyé. Le champ Nr, Serv pour les sessions L2TP. (0)

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 9

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

Tableau 4 – AVPs spécifiques à Diff Serv 6.1 AVPs

Attribute Il y a deux AVPs pouvant entrer en jeu dans la sécurité pour
AVP Description L2TP :
Type
Il informe l’autre extrémité du ■ Le premier est l’AVP Random Vector (Attribute Type 36) utilisé
tunnel que l’initiateur du tunnel conjointement avec le bit H (Hidden ) de l’en-tête L2TP (figure 4,
Control Connection L2TP (LAC ou LNS) veut utiliser la tableau 1) qui permet de dissimuler la valeur d’un AVP grâce à une
DS (CCDS) 47 fonction Per-Hop Behavior pour chaîne de caractères aléatoires permettant de faire un hash avec
tous les paquets de la connexion l’algorithme MD5. Ainsi, seuls le LAC et le LNS, qui possèdent un
de contrôle. secret partagé, peuvent décoder les valeurs des AVPs reçus.
Il informe l’autre extrémité du ■ Le second est l’AVP Challenge (et sa réponse l’AVP Challenge
tunnel que l’initiateur de la session Response ). À eux deux, ils assurent l’authentification des extré-
Session DS (SDS) 48 L2TP veut utiliser la fonction
Per-Hop Behavior de Diff Serv mités du tunnel grâce à un mécanisme de type CHAP (Challenge
pour tous les paquets de la ses- Handshake Authentification Protocol ).
sion. L’utilisation conjointe de l’AVP Challenge avec le bit H positionné
à 1 renforce la sécurité de cet échange de messages.

Un message SCCRQ (respectivement ICRQ ou OCRQ), contenant

un AVP CCDS (respectivement SDS) est envoyé par le LAC ou le LNS. 6.2 L2TP et RADIUS
• Si le récepteur du message ne peut supporter un tel AVP, il
l’ignore et renvoie un message SCCRP (respectivement ICRP ou L’utilisation du protocole RADIUS en collaboration avec le pro-
OCRP) sans AVP CCDS (respectivement SDS). Diff Serv ne pourra tocole de tunneling L2TP présente deux avantages principaux
être initié entre cette paire LAC-LNS ; libre à l’initiateur du tunnel fortement liés :
(respectivement de la session) de continuer la procédure. — une authentification basée sur le nom de l’utilisateur distant
plutôt que sur sa localisation sur le réseau ;
• Dans le cas contraire, le récepteur du message SCCRQ
— l’avantage de regrouper l’ensemble des utilisateurs distants
(respectivement ICRQ ou OCRQ) renvoie un message SCCRP (res-
dans une seule base que pourraient consulter les différents LAC ou
pectivement ICRQ ou OCRQ) contenant lui aussi un AVP CCDS
LNS.
(respectivement SDS).
Ainsi, un utilisateur distant, quelle que soit sa localisation et
Le LAC et le LNS sont donc en accord pour utiliser les fonction-
donc quel que soit le NAS qu’il utilise, serait autorisé à se
nalités de Diff Serv sur le tunnel initié (respectivement la session)
connecter à un réseau distant via le protocole L2TP, après plusieurs
et offrir une meilleure qualité de service à la connexion.
authentifications successives.
Remarque : le Per-Hop Behavior décrit le comportement d’un nœud Le client contacte son NAS et initie une session PPP, le NAS inter-
concernant la retransmission des paquets reçus. Un exemple d’un tel roge alors la base de données RADIUS pour authentifier
comportement est la garantie d’une bande passante minimale sur un l’utilisateur. Cela fait, le LAC initie alors une connexion de contrôle,
lien. puis une session L2TP. Une autre authentification du client sera
alors effectuée au niveau du LNS pour s’assurer de son identité et
pour autoriser son appel.
5.4 Bit de priorité (bit P)
L’en-tête L2TP (figure 4 et tableau 1) contient un drapeau permet- 6.3 L2TP et IPsec
tant de donner la priorité à certains messages de données. Cela peut
servir à s’assurer qu’un lien ne va pas être arrêté à cause de la L’utilisation conjointe d’IPsec avec L2TP est recommandée par
lenteur de traitement des données due à une congestion locale. l’IETF pour assurer l’authenticité, l’intégrité et la confidentialité
Ainsi, il est intéressant de mettre ce bit à 1 pour des messages de des données échangées à un niveau supérieur que celui offert par
données tels que l’echo request de LCP, qui est utilisé pour s’assurer L2TP seul.
de l’état actif du lien. De cette manière, s’il existe un engorgement
quelconque au niveau du LAC ou du LNS, ce message, ayant son Permettant déjà deux étapes d’authentification (aux niveaux PPP
bit de priorité positionné, se verra offrir un traitement privilégié et et L2TP), le protocole L2TP a surtout besoin d’un protocole de
donc plus rapide. La perte de connexion due à une surcharge du chiffrement. Il doit donc supporter le protocole ESP (Encapsulating
nombre de messages à traiter par l’une des extrémités du tunnel Security Payload ) d’IPsec, ainsi qu’un mécanisme de gestion des clés
peut être évitée grâce à ce bit. de cryptage (par exemple IKE, Internet Key Exchange ). Cependant,
les authentifications effectuées par PPP et L2TP n’interviennent qu’en
début de session, contrairement à IPsec qui propose avec le pro-
tocole AH (Authentification Header ) une authentification de chaque
6. Sécurité dans L2TP paquet reçu. Les protocoles AH et ESP sont généralement utilisés
conjointement.
Fonctionnement d’IPsec avec L2TP :
La sécurité dans L2TP se compose essentiellement de mécanismes
d’authentification. Transportant des trames PPP, l’authentification à Le client ne connaissant pas le réseau entre lui et le LAC (ni le
ce niveau permet déjà un minimum de sécurité, accompagné le plus niveau de sécurité qui y est appliqué), de même que le niveau de
généralement par une authentification du tunnel (c’est-à-dire des sécurité entre le LAC et le LNS, il va négocier directement avec le
extrémités communicantes, le LAC et le LNS). De plus, la définition LNS les options de sécurité qu’il désire ; notamment le cryptage
de certains AVPs a permis de renforcer cette sécurité. Finalement, utilisé (protocole ESP d’IPsec) et éventuellement l’authentification
des combinaisons de L2TP avec des mécanismes de sécurité bien de paquets (protocole AH).
connus ont été définies ; ainsi, l’utilisation de L2TP avec IPsec est Le client envoie donc un paquet vers le LNS afin de créer une
recommandée par l’IETF, et l’utilisation conjointe de L2TP et de relation de confiance entre lui et le LNS, basée sur IPsec. Cette
RADIUS ajoute encore à la sécurité des échanges. relation établie, tous les paquets envoyés par le client utiliseront

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 10 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

IP AAL5 LAYER
en-tête IPsec Destination SAP (0xAA)
en-tête PPP Source SAP (0xAA) LLC header
en-tête L2TP Frame Type = UI (0x03)
Couche de liaison ou IP/UDP OUI = (0x00-00-5E)
SNAP header
PID (0x0007)
Figure 8 – Encapsulation IPsec d’un paquet L2TP
L2TP packet L2TP data

IPsec. Le LAC, recevant de tels paquets, ajoute une encapsulation

L2TP et expédie le message vers le LNS. Ce dernier doit s’assurer
que le paquet a bien été codé avec IPsec, qu’il n’a pas circulé en Figure 9 – Encapsulation LLC d’un paquet L2TP
clair (protocole ESP) et que l’expéditeur du paquet est bien
authentifié (protocole AH).
Il désencapsule alors L2TP et IPsec. Le message original est ainsi
récupéré par le LNS qui le fait suivre à la bonne destination. IPsec
assure ainsi un échange sécurisé de données, le tunnel L2TP CPCS-PDU payload
n’étant pas sécurisé en soi, mais les données transportées à L2TP PDU
(jusqu'à 216–1 octets)
l’intérieur l’étant.
Les données sont donc transportées dans un tunnel IPsec (entre PAD (de 0 à 47 octets)
le client et le LNS), lui-même transporté dans un tunnel L2TP CPCS-UU (1 octet)
(entre le LAC et le LNS). Les données transportées par le tunnel
CPI (1 octet) CPCS-PDU
sont donc cryptées et ne peuvent être décryptées par un tiers.
Longueur (2 octets) Trailer
L’encapsulation totale présente entre le LAC et le LNS est repré-
senté sur la figure 8. CRC (4 octets)
Ainsi, grâce au mécanisme d’authentification L2TP des extré-
mités du tunnel (avec le protocole CHAP), le LAC et le LNS sont
Figure 10 – Format d’un paquet AAL5 CPCS-PDU
authentifiés et peuvent communiquer entre eux ; avec le protocole
IPsec, l’utilisateur distant et le LNS sont reconnus et chacun peut
vérifier que le paquet reçu est bien crypté avec IPsec et que la
source du paquet est authentifiée. qu’un identifiant de protocole (PID, Protocol ID) d’une valeur hexa-
décimale 0x07 représentant, pour l’IANA, le protocole L2TP.
Cette encapsulation doit être supportée par L2TP sur des circuits
virtuels permanents.
7. Utilisations de L2TP sur Dans le cas d’un multiplexage sur circuit virtuel, le paquet L2TP
les protocoles de niveau 2 est en fait la charge utile de la couche d’adaptation ATM, sans
en-tête LLC, mais des champs sont rajoutés à la fin du paquet,
comme présenté sur la figure 10.
7.1 L2TP over ATM Adaptation Layer 5 CPCS-PDU payload (Common Part Convergence Sub-layer ) :
(AAL5) contient en fait le paquet L2TP (voir section ZZ décrivant un paquet
L2TP). Ce champ peut contenir jusqu’à 216–1 octets.
En tant que connexion orientée paquet, ATM permet l’utilisation Le champ PAD permet d’ajouter un certain nombre d’octets afin
du protocole L2TP pour les connexions point à point. Le tunnel que la SAR (Segmentation And Reassembly sub-layer ) puisse
L2TP sur ATM équivaut alors à l’établissement d’un circuit virtuel découper correctement le paquet en un nombre entier de cellules
ATM (permanent ou à la demande). ATM.
Nota : la couche d’adaptation ATM de niveau 5 sert de liaison entre les couches logi- Le CPCS-UU (User to User information ) n’a pas d’utilité dans
cielles et la couche de bas niveau. L’AAL5 comporte 2 composantes : la sous-couche de notre cas, il peut prendre n’importe quelle valeur.
convergence (Convergence Sub-layer, CS) et la sous-couche de segmentation et
de réassemblage (Segmentation And Reassembly sub-layer, SAR). La CS encapsule les Le champ CPI sert à aligner le CPCS-PDU trailer sur 64 bits.
paquets applicatifs dans des paquets de différentes tailles et gère ainsi toute la partie
contrôle de ces paquets (temps de transmission, pertes, erreurs) ; la SAR, quant à elle, L’avant-dernier champ spécifie la longueur de la payload en
découpe les paquets encapsulés afin de les intégrer à des cellules ATM (48 octets). octets.
Pour encapsuler un protocole sur une couche d’adaptation ATM Les points importants lors de l’utilisation de L2TP sur ATM sont :
de niveau 5, deux possibilités se présentent : ● Lors d’une demande de connexion pour un circuit virtuel
— une encapsulation LLC (Logical Link Control ) ; commuté (SVC, Switched Virtual Circuit ), le demandeur doit
— un multiplexage sur circuit virtuel. spécifier dans son message SETUP s’il propose un multiplexage sur
circuit virtuel, une encapsulation LLC pour L2TP ou les deux. Au
Un paquet L2TP ayant une encapsulation LLC est représenté moins, l’encapsulation LLC doit être supportée par les deux
figure 9. machines établissant la liaison point-à-point.
L’en-tête LLC (destination SAP=0xAA, source SAP=0xAA, Frame ● Chaque paquet L2TP doit être transporté dans un paquet AAL5
Type=0x03) indique que le prochain en-tête est un en-tête SNAP et un seul ; il est donc important de bien régler le MTU (Maximum
(SubNetwork Access Protocol ). Transfer Unit ) de la connexion ATM, qui doit alors prendre en
L’en-tête SNAP indique un numéro OUI (Organizationnaly Unique compte le MTU du tunnel L2TP et les MTU de chaque connexion PPP
Identifier) sur 3 octets qui représente l’IANA (Internet Assigned à l’intérieur du tunnel. Il est recommandé que la taille d’un paquet IP
Numbers Authority, représenté par la valeur 0x00-00-5E) ainsi transporté dans PPP soit d’au moins 9 180 octets.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 11

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

Utilisateur IP
distant LAC LNS
en-tête PPP 8 octets
LANs en-tête L2TP 14 octets
en-tête UDP 8 octets
Réseau Réseau en-tête IP 20 octets
d'interconnexion Frame relay
(PSTN/ISDN) Layer 2

Figure 11 – Architecture L2TP sur Frame Relay Figure 13 – Empilement protocolaire pour L2TP sur IP

en transportant des trames PPP dans des paquets IP. Il peut alors
servir à la création de réseaux privés virtuels (VPN, Virtual Private
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Network ).
Q 922 address
Le protocole L2TP dans cette utilisation repose sur UDP. Les
Control 0x03 pad 0 paquets à transporter sont encapsulés dans un datagramme UDP
NLPID 0x80 OUI 0x00 (port 1701) et envoyés au destinataire ; cela permet notamment de
OUI 0x00-5E traverser les équipements utilisant de la traduction d’adresse (NAT,
PID 0x0007
Network Address Translation ).
L’extrémité qui demande l’ouverture d’un tunnel L2TP choisit un
L2TP Packet port source quelconque (qui peut être le port 1701 ou pas) et
envoie les datagrammes au destinataire sur le port 1701. La
FCS
seconde extrémité, acceptant l’ouverture du tunnel, utilise éga-
lement le port 1701 en tant que port de destination et choisit un
NLPID : Network Level Protocol ID port de source UDP libre (port 1701 ou non). Ces numéros de port
Champ d'un octet permettant de connaitre
seront conservés par les deux extrémités du tunnel afin d’utiliser
facilement le protocole supérieur.
toujours les mêmes durant toute la durée du tunnel.
OUI : Organizationnally Unique Identifier La figure 13 montre l’empilement protocolaire que représente
3 octets indiquant l'organisation qui gère la cette technique de tunneling ainsi que le nombre d’octets par
valeur du champ PID. La valeur 0x00-00-5E en-tête ajouté (on considère qu’IP n’a pas d’options particulières).
représente l'IANA.
En tenant compte de la taille des différents en-têtes, cela donne
PID : Protocol ID
une encapsulation d’au plus 50 octets. C’est un des principaux
La valeur 0x0007 a été définie par l'IANA inconvénients de l’utilisation de L2TP sur IP.
comme identifiant le protocole L2TP. À cause de cet overhead assez conséquent, il convient de porter
une attention particulière à la valeur des MRU et MTU (Maximum
Receive Unit et Maximum Transfer Unit ) des équipements IP tra-
Figure 12 – Encapsulation Frame Relay d’un paquet L2TP
versés et de les définir judicieusement afin d’éviter la fragmentation
des paquets de grande taille.
7.2 L2TP over Frame Relay
Le protocole L2TP peut également être utilisé sur un réseau
Frame Relay ; aussi bien sur les circuits virtuels permanents que 8. Conclusion
sur les circuits virtuels commutés.
L’utilisateur distant désirant établir une connexion PPP avec une L’idée première du protocole L2TP était de transporter des sessions
machine du réseau initie une session PPP jusqu’au LAC (situé entre PPP jusqu’à des points de terminaison n’importe où dans le réseau.
le réseau d’interconnexion du client et le réseau Frame Relay ) qui Depuis, une nouvelle utilisation du protocole est envisagée, celle de
entame alors la négociation d’un tunnel L2TP sur le réseau Frame pouvoir transporter d’autres protocoles de niveau 2.
Relay afin d’y faire circuler la session PPP jusqu’au LNS (figure 11). Pour répondre à ce nouveau besoin, une nouvelle version du
Lors de l’établissement d’un circuit virtuel sur le réseau Frame protocole L2TP a été standardisée par le RFC3931 (cf. référence
Relay, tous les protocoles utilisant ce circuit doivent être encapsu- [7]) : L2TPv3. Un des buts les plus importants de cette nouvelle ver-
lés dans une trame de type Q.922. Le protocole L2TP, de même que sion, standardisée en mars 2005, est de rendre le protocole indé-
tous les protocoles transitant sur ce circuit virtuel verront leur pendant de PPP et plus généralement, de le rendre indépendant de
en-tête modifié comme sur la figure 12. tout protocole de niveau 2 qu’il doit transporter. D’autres différen-
ces avec le RFC 2661 (cf. référence [4]) comme l’extension de la
Avec une telle encapsulation, la taille du MTU sur le circuit vir- taille des identificateurs de session et de tunnel (session ID et tun-
tuel utilisé doit être configurée avec précaution ; spécialement si la nel ID ) et l’authentification de tous les messages de contrôle (plu-
fragmentation des paquets n’est pas supportée. En tenant compte tôt que d’une partie seulement) sont également à noter.
de la taille du MRU PPP et de la taille maximale des en-têtes PPP,
L2TP et Frame Relay, une taille minimale de 1 526 octets doit être Cette version 3 du protocole L2TP devrait permettre d’élargir
attribuée au MTU du circuit. encore l’interconnexion des sites en offrant la possibilité à de nom-
breux protocoles de niveau 2 d’être transportés sur n’importe quelle
couche de liaison tout en apportant un niveau de sécurité plus élevé.
7.3 L2TP sur IP/UDP Par ailleurs, le groupe de travail Softwires de l’IETF, qui a en
charge la recherche de solution pour interconnecter les réseaux
L’utilisation du protocole L2TP sur IP/UDP est l’une des plus fré- IPv4 et IPv6, a choisi le protocole L2TP pour y parvenir en utilisant
quentes de ce protocole. Cela sert à faire du tunneling sur Internet les techniques de tunneling IPv4/IPv6 et IPv6/ IPv4.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 12 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
 ______________________________________________________________________________________________________________________ PROTOCOLE L2TP

9. Annexe : les différentes paires valeur/attribut (AVP)

Tableau 5 – AVPs pouvant être dans tous les message de contrôle

AVP Name Attribute Type Description
Message Type 0 Indique le type de message de contrôle dans le champ Attribute Value par un entier codé sur deux
octets. Cet AVP doit être le premier AVP à figurer dans un message de contrôle.
Random Vector 36 Permet de crypter la valeur du champ Attribute Value de n’importe quel AVP ayant le bit H à 1. Il doit
précéder le premier AVP avec un tel bit.

(0)

Tableau 6 – AVPs gérant la connexion de contrôle

Messages
AVP name Attribute Type Description
de contrôle
Indique la version du protocole L2TP utilisée par l’expéditeur du message. Le premier SCCRQ,
Protocol Version 2 champ (un octet) de l’Attribute Value correspond à la version du protocole (Ver ), le SCCRP
second (un octet) à la révision du protocole (Rev ).
Permet la transmission d’information sur le type de trames qui seront envoyées ou qui
Framing Capabilities 3 pourront être reçues par l’expéditeur de cet AVP. Les 2 derniers bits sur 32 sont actuel- SCCRQ,
lement utilisés. Une émission asynchrone des trames est supportée si l’avant-dernier bit SCCRP
est à 1, une émission synchrone, si le dernier bit est à 1.
Donne des renseignements sur le type de couche de transport supportée par les inter-
faces de l’expéditeur de cet AVP. Les 2 derniers bits sur 32 sont actuellement utilisés. Un SCCRQ,
Bearer Capabilities 4 support analogique peut être utilisé si l’avant-dernier bit est à 1, un support digital, si le SCCRP
dernier bit est à 1.
Indique que l’expéditeur du message ne souhaite établir qu’un unique tunnel pour cette
Tie Breaker 5 paire LAC-LNS. SCCRQ

SCCRQ,
Firmware Revision 6 Indique le numéro de révision du firmware de l’interface émettrice. SCCRP
Indique le nom de l’émetteur du message (LAC ou LNS). La longueur de ce champ est SCCRQ,
Host Name 7 variable et dépend du nom de l’émetteur, mais il doit faire au minimum 1 octet. SCCRP

Vendor Name 8 Décrit le type de LAC ou de LNS utilisé. SCCRQ,

SCCRP

Représente le numéro d’identification attribué au tunnel par l’expéditeur du message. Cet SCCRQ,
Assigned Tunnel ID 9 AVP permet d’identifier à quel tunnel un message appartient. SCCRP,
StopCCN
Receive Window 10 Donne la taille de la fenêtre de réception de l’expéditeur du message. SCCRQ,
Size SCCRP

Challenge 11 Demande l’authentification CHAP des extrémités du tunnel à l’expéditeur du message. La SCCRQ,
longueur du champ Attribute Value est d’au moins un octet. SCCRP
Répond à l’AVP Challenge reçu dans le précédent message pour l’authentification de la SCCCN,
Challenge Response 13 machine. SCCRP

(0)

Tableau 7 – AVPs s’occupant de la gestion des appels

Messages
AVP name Attribute Type Description
de contrôle
CDN, ICRQ,
Équivalent de l’AVP Assigned Tunnel ID pour la session L2TP. Il contient donc la valeur ICRP,
Assigned Session ID 14 attribuée par l’émetteur pour cette session particulière et permet donc de savoir à quelle OCRQ,
session un message appartient.
OCRP

Call Serial Number 15 Identifiant attribué par le LAC ou le LNS à la session PPP. ICRQ,
OCRQ

Minimum BPS 16 Vitesse de connexion minimale pour la session PPP. La valeur de cette vitesse est codée OCRQ
sur 32 bits et exprimée en bits par seconde.

Maximum BPS 17 Vitesse de connexion maximale pour la session PPP. La valeur de cette vitesse est codée OCRQ
sur 32 bits et exprimée en bits par seconde.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. TE 7 579 − 13

Dossier délivré pour

DOCUMENTATION
21/10/2008
PROTOCOLE L2TP ______________________________________________________________________________________________________________________

Tableau 7 – AVPs s’occupant de la gestion des appels (suite)

Messages
AVP name Attribute Type Description
de contrôle
Donne des informations sur le type de canal de transmission utilisé par l’expéditeur du
Bearer Type 18 message. Les 2 derniers bits sur 32 sont actuellement utilisés. Un canal de transmission ICRQ,
analogique peut être utilisé si l’avant-dernier bit est à 1, un canal de transmission digital, OCRQ
si le dernier bit est à 1.
ICCN,
Framing Type 19 Similaire à l’AVP Framing Capabilities, il spécifie si l’envoi des trames pourra se faire de OCCN,
manière asynchrone (avant-dernier bit à 1) ou de manière synchrone (dernier bit à 1). OCRQ
Indique le numéro de téléphone à appeler si le message vient du LNS et le numéro de
Called Number 21 téléphone appelé si le message vient du LAC. Ce numéro n’est pas codé sur une taille fixe ICRQ,
car il dépend de la longueur du numéro. OCRQ

Indique le numéro de téléphone de l’initiateur de l’appel, c’est-à-dire du client. Ce numéro

Calling Number 22 n’est pas codé sur une taille fixe car il dépend de la longueur du numéro. ICRQ

Fournit des informations complémentaires relatives à l’appel. Cet AVP est codé sous la ICRQ,
Sub-Address 23 forme d’une chaîne de caractères. OCRQ

(Tx) Connect Speed 24 Donne la vitesse de transmission de la connexion du LAC vers le système distant. Cette ICCN,
vitesse, codée sur 4 octets, est donnée en bits par seconde. OCCN
Informe si l’authentification du proxy doit avoir lieu ou non. La valeur de cet AVP est
Proxy Authen Type 29 codée sur 2 octets et donne le type d’authentification (user/password, PPP CHAP, PPP ICCN
PAP, no authentification, MSCHAPv1)
Proxy Authen Type 30 Contient le nom du client à authentifier. Il est recommandé de crypter cet AVP. ICCN
Proxy Authen 31 Contient le Challenge envoyé par le LAC à l’extrémité du tunnel PPP lorsque l’authenti- ICCN
Challenge fication de proxy est demandée.
Proxy Authen 33 Spécifie la réponse envoyée par l’extrémité PPP au LAC à propos de l’authentification du ICCN
Response proxy.

Private Group ID 37 Permet au LAC de préciser que cet appel doit être associé à un groupe particulier ICCN
d’utilisateurs.
Donne la vitesse de réception de la connexion du point de vue du LAC, c’est-à-dire du ICCN,
(Rx) Connect Speed 38 système distant vers le LAC. Si cet AVP n’est pas présent, on considère que la connexion OCCN
est symétrique et que la vitesse de réception correspond à la vitesse de transmission.
Sequencing 39 Indique au LNS que la numérotation des paquets de données est obligatoire. Cet attribut ICCN,
Required n’a pas de champ Attribute Value. OCCN

(0)

Tableau 8 – AVPs transportant des messages d’erreur

Messages
AVP name Attribute Type Description
de contrôle
Indique la raison pour laquelle une connexion de contrôle ou une session est terminée ;
raison codée dans le champ Result Code et dépendant du type du message. Cet AVP peut CDN,
Result Code 1 également contenir un code et un message d’erreur, codé chacun sur 2 octets. Le StopCCN
message d’erreur est codé en ASCII pour pouvoir être lu.
Q.931 Cause Code 12 Donne des informations complémentaires sur une déconnexion imprévue d’une session. CDN
Permet au LAC d’envoyer des informations sur les erreurs survenues vers le LNS. Cet
Call Errors 34 WEN
AVP peut contenir des informations sur les erreurs de CRC, de trames PPP mal formées.

ACCM 35 Le message contenant l’AVP ACCM (Asynchronous Control Character Map ) est envoyé SLI
par le LNS pour indiquer au LAC la valeur de l’ACCM négociée par le LNS.

Références bibliographiques
[1] RFC 1700. – Assigned Numbers. [4] RFC 2661. – Layer Two Tunneling Protocol [6] RFC 3308. – Layer Two Tunneling Protocol
[2] RFC 2341. – Cisco Layer Two Forwarding (Pro- (L2TP) (L2TP) Differentiated Services Extension
tocol) L2F
[3] RFC 2637. – Point-to-Point Tunneling Protocol [5] RFC 2784. – Generic Routing Encapsulation [7] RFC 3931. – Layer Two Tunneling Protocol –
(PPTP) (GRE) Version 3 (L2TPv3)

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 579 − 14 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008