F R A M E I P.

C O M
Partage des connaissances du monde TCP/IP
(http://www.frameip.com/)

ARCHITECTURE L2TP – LAYER 2

TUNNELING PROTOCOL

Sommaire [Masquer]

1 – Introduction à l’architecture L2TP

2 – Histoire
2.1 – Rappel du contexte technico-économique
2.2 – Les différentes connexions « Haut débit » par modem xDSL
2.3 – L’alternative PPPoE
2.4 – Statut de PPP over Ethernet
3 – Le protocole PPP
3.1 – Introduction
3.2 – Format de l’entête
3.3 – Etablissement d’une connexion
3.4 – LCP – Link Control Protocol
3.5 – NCP – Network Control Protocols
3.6 – Authentification
4 – Le protocole PPPoE
4.1 – Introduction
4.2 – L’histoire
4.3 – Format de l’entête
4.4 – Les étapes
4.5 – Sécurité
5 – Le protocole L2TP
5.1 – Introduction
5.2 – Format de l’entête
5.3 – Les concentrateurs d’accès – LAC
5.4 – Les serveurs réseau – LNS
5.5 – Avantages et inconvénients
6 – L’architecture PPP – L2TP
6.1 – Architecture IP
6.2 – Les encapsulations
6.3 – Les tailles maximums de l’OverHead
6.4 – Problématique liée au MTU
7 – Conclusion
8 – Suivi du document
9 – Discussion autour de l’Architecture L2TP – Layer 2 Tunneling Protocol
Commentaire et discussion
Laisser un commentaire

1 – Introduction à l’architecture L2TP

La première partie du dossier est un peu théorique. Après un bref rappel du contexte
technico-économique et des différentes problématiques rencontrées par les fournisseurs
d’accès à Internet (ISP) avec les connexions « Haut Débit » chez le particulier (technologies
xDSL ou liaison câble), le protocole PPPoE sera présenté en détail ainsi que PPP afin
d’aborder L2TP. La seconde partie du document est plus orientée pratique. Elle décrit la mise
en place d’une solution L2TP et présente les différentes encapsulations et taille des trames.
L2TP, définit par la RFC 2661 (http://www.frameip.com/rfc-2661-layer-two-tunneling-
protocol-l2tp/), est issu de la convergence des protocoles PPTP et L2F. Il est actuellement
développé et évalué conjointement par Cisco Systems, Microsoft, Ascend, 3Com ainsi que
d’autres acteurs clés du marché des réseaux. Il permet l’encapsulation des paquets PPP au
niveau des couches 2 (Frame Relay et ATM) et 3 (Ip). Lorsqu’il est configuré pour transporter
les données sur IP, L2TP peut être utilisé pour faire du tunnelling sur Internet. L2TP repose
sur deux concepts : les concentrateurs d’accès L2TP (LAC : L2TP Access Concentrator) et les
serveurs réseau L2TP (LNS : L2TP Network Server). L2TP n’intègre pas directement de
protocole pour le chiffrement des données. C’est pourquoi L’IETF préconise l’utilisation
conjointe d’IPSEC et L2TP.

2 – Histoire

2.1 – Rappel du contexte technico-économique

Les services Internet proposés au particulier et aux petites entreprises sont de plus en plus
nombreux (connexion via un fournisseur d’accès, travail à distance, services à valeur ajoutée
tels que l’e-mail, serveur Web hébergé, VPN (http://www.frameip.com/vpn/), etc.). Cette
population appelée communément SOHO (Small Office / Home Office) est la cible des grands
de l’industrie du réseau (opérateurs, constructeurs, etc.).
En effet, le besoin de connexion à « Haut-débit » est de plus en plus fort, mais face à des
technologies de plus en plus complexes, les déploiements sont ralentis car trop coûteux
(liens fibres optiques, terminaux de connexion ATM), trop spécifiques (encapsulations
multiples des protocoles pour interfacer PC et modem) ou encore trop difficiles à mettre en
place par les opérateurs (configuration, formation des utilisateurs).
Différentes propositions ont été faites afin de « standardiser » et « simplifier » le mode de
connexion entre un micro-ordinateur personnel PC et un modem de type xDSL ou modem
câble. Ces différentes solutions sont présentées en paragraphe II.2.
Rappelons que les objectifs qui animent ces recherches sont la facilité et la vitesse de
déploiement des connexions « Haut débit » chez les consommateurs SOHO, et de surcroît à
moindre coût !

2.2 – Les différentes connexions « Haut débit » par modem xDSL

Dans le cas de connexion par RTC (Réseau Téléphonique Commuté), les utilisateurs finaux
(SOHO ou particuliers pour un usage privé) sont habitués à utiliser un matériel « banalisé »
comme un modem analogique fonctionnant en bande téléphonique analogique (30Hz -> 3,6
KHz), dont le coût d’achat est faible, et surtout dont la configuration est minimale (utilisation
des protocoles PPP, SLIP, RAS, etc. nativement gérés par les systèmes d’exploitations les
plus répandus du marché).
Dans le cadre des connexions « Haut-débit », un matériel plus sophistiqué de type modem
xDSL ou modem câble est nécessaire. Son coût d’acquisition est plus élevé que dans le cas
précédent, et la configuration est plus complexe car elle s’appuie sur des technologies plus
élaborées.
Les recherches menées par l’industrie du réseau et des télécommunications ont abouti à
plusieurs propositions d’architecture décrites ci-après, chacune basée sur les technologies
ATM sur xDSL. Un des objectifs étant la simplicité de configuration, le protocole PPP a été
retenu comme point de départ. Chacune des solutions diffère sur le mode de connexion
entre le micro-ordinateur et le modem xDSL.

2.2.1 – ATM sur interface xDSL

Le schéma suivant présente la première proposition de configuration.
Une carte d’interface xDSL est implantée directement dans le micro-ordinateur, sur lequel
sont installés un driver PPP et un driver ATM. L’avantage principal est l’utilisation de PPP
pour l’utilisateur, donc la configuration et la procédure de connexion est connue car
identique à celle utilisée dans le cas de connexion analogique par RTC. La connexion PPP
s’effectue au travers de la boucle locale jusqu’au réseau de données régional vers un POP
(Point-Of-Presence) de fournisseur d’accès.
Deux inconvénients majeurs à cette architecture :
Le marché des interfaces xDSL n’en est qu’à ses premiers pas et le manque d’inter-
opérabilité entre les différents équipements xDSL ne permet pas la réalisation
d’économies d’échelles nécessaires pour la production d’interfaces xDSL standards à
coût réduit.
La ligne xDSL ne peut être utilisée que par un seul micro-ordinateur à la fois, ce qui
limite l’intérêt de ce type de connexion pour les SOHO.

2.2.2 – Interface ATM et modem xDSL

La seconde proposition d’architecture est présentée dans le schéma ci-dessous.

Les limites reconnues d’une interface xDSL, les approches suivantes, dont celle-ci, s’appuient
sur un équipement xDSL externe (modem). La configuration proposée ici repose sur un lien
ATM entre le micro-ordinateur et le modem xDSL. A cet effet, une interface ATM est implantée
dans le PC.
Les inconvénients de cette proposition sont les suivants :
Les interfaces ATM sont peu répandues chez les utilisateurs finaux. Cette
configuration était la première hypothèse des opérateurs pour le déploiement des
connexions « Haut débit » chez le consommateur. Pour rappel, elle n’a pas été
retenue pour des raisons économiques. De plus, ce type d’interface est difficile à
installer et à configurer par l’utilisateur. Cette complexité risque de ralentir le
déploiement et l’acceptation de la technologie xDSL chez les consommateur.
Il n’existe pas d’interface ATM pour les micro-ordinateurs portables, ce qui est un
inconvénient pour les SOHO, le plus souvent nomades.
Le partage d’une telle connexion nécessite l’utilisation d’un commutateur ATM, ce qui
 rend difficile, voir quasi impossible le déploiement d’un telle solution.

2.2.3 – Interface Ethernet, L2TP sur IP et modem xDSL

La troisième solution est présentée dans le schéma suivant.

Cette architecture est plus « ouverte » dans la mesure où le lien entre le micro-ordinateur et
l’équipement xDSL repose sur une technologie éprouvée : Ethernet. En effet, le modem xDSL
dispose d’un banal connecteur Ethernet qui peut être soit attaché directement à une carte
Ethernet implantée dans le client PC (liaison à l’aide d’un câble « croisé » ou « droit » ), soit
indirectement via un Hub (ou Switch) Ethernet. Le micro-ordinateur doit être configuré
comme sur un réseau local d’entreprise (LAN : Local Area Network), c’est à dire : posséder
un driver de carte réseau (NIC Ethernet), une pile de protocole TCP/IP
(http://www.frameip.com/tcpip/), et une couche logicielle permettant la gestion de sessions
PPP (pour la connexion à l’ISP).
Cette topologie a l’avantage de permettre le partage de la connexion xDSL au travers d’un
réseau. Autre avantage d’un telle architecture : le coût peu élevé de l’équipement. A noter
quand même les quelques inconvénients suivants :
Cette configuration n’intègre pas nativement ce qui est nécessaire au départ, à
savoir un mécanisme de transport et de gestion de sessions PPP au travers
d’Ethernet. L’utilisation d’un protocole de « tunneling » comme L2TP (ou PPTP) peut
s’avérer un moyen pour assurer le transport de PPP sur IP, mais ajoute une
complexité à la configuration.
Le modem xDSL doit, dans ce type de solution, posséder une adresse IP
(configurable de préférence) pour la communication au niveau du réseau Ethernet.
Le client PC a donc quant à lui deux adresses IP : la première pour la connexion au
réseau Ethernet (afin d’établir correctement le tunnel L2TP), la seconde pour la
liaison PPP vers un ISP.
Quelles adresses IP utiliser pour établir le tunnel L2TP entre le client PC et le modem
xDSL ? Une des réponses possibles à cette problématique est l’implantation et
l’utilisation combinée de mécanismes comme NAT (Network Address Translation
(http://www.frameip.com/nat/) : translation d’adresses IP d’un réseau vers un
autre) et DHCP (http://www.frameip.com/dhcp/) (attribution dynamique d’une
adresse IP à un client, à partir de plages définies). Même si ces techniques sont
connues et maîtrisées dans le monde du réseau, elles sont loin d’être à la portée
des utilisateurs finaux.

2.2.4 – Interface Ethernet, ATM sur BMAP et modem xDSL

La quatrième et dernière architecture proposée est la suivante.
Les inconvénients apportés par l’utilisation d’un protocole de « tunneling » comme L2TP pour
transporter du PPP sur de l’Ethernet ont entraîné le développement d’un nouveau protocole
baptisé BMAP (Broadband Modem Access Protocol). Dans l’approche qui est présentée sur le
schéma ci-avant, la configuration reprend le principe de PPP sur ATM, mais le transport entre
le client PC et le modem xDSL sur Ethernet, est assuré par ce protocole BMAP. La
configuration de l’équipement xDSL est nettement simplifiée, mais cette solution apporte
d’autres inconvénients que ceux cités auparavant :
La pile de protocole au niveau du client PC est bien plus complexe que le modèle
Dial-up standard. Alors que ce dernier consiste à adresser directement le modem
analogique à partir du protocole PPP, le modèle présenté ici introduit un réseau
Ethernet et de l’ATM cohabitant avec du BMAP pour transporter le protocole PPP vers
le modem xDSL. La complexité d’un telle configuration est donc une fois de plus mise
en avant.
Concernant le partage de la connexion : la nature du protocole BMAP est telle que si
plusieurs clients PC veulent accéder au modem xDSL (donc à la même ligne) au
même moment, un des micro-ordinateurs du réseau doit être défini pour fonctionner
en mode passerelle, relayant ainsi le trafic des autres postes vers le modem. Cet
aspect augmente encore le niveau de complexité de cette solution.
Pas ou peu d’équipement xDSL intègre la gestion du protocole BMAP. De plus, il n’y a
pas encore de drivers BMAP disponibles pour les systèmes d’exploitations Windows.

2.2.5 – Conclusion
En conclusion de la présentation de ces quatre propositions, il apparaît chaque fois plus
d’inconvénients que d’avantages. D’un côté la configuration à mettre en place est soit trop
coûteuse ou soit trop complexe pour l’utilisateur final, d’un autre côté les équipements
n’intègrent pas les fonctionnalités nécessaires. C’est pour cette raison qu’aucune d’entre
elles n’a été retenue.

2.3 – L’alternative PPPoE

La solution qui a été retenue a donné naissance à un nouveau protocole baptisé PPPoE :
PPP over Ethernet. Comme son nom l’indique, cette technique repose sur le meilleur des
deux mondes :
Le protocole PPP pour la communication avec un ISP au travers de l’architecture
xDSL mise en place. Respectant un des objectifs majeurs initiaux, la solution se
rapproche du modèle Dial-Up bien connu. L’utilisateur final a déjà une connaissance
de l’utilisation et de la configuration de ce mode de connexion.
La topologie Ethernet pour le partage du modem xDSL au travers d’un réseau local
bâti autour de Hub (ou Switch) ou de rattachement direct au client PC dans lequel
est implantée une carte d’interface Ethernet (NIC), s’appuyant ainsi sur un standard
de l’industrie.
Le schéma suivant présente l’architecture PPPoE :
Le modem xDSL peut être préconfiguré par l’opérateur (CVP pour le lien opérateur),
réduisant ainsi le temps d’installation d’une telle solution chez l’utilisateur final. Ce dernier
n’a plus que quelques étapes à réaliser pour finaliser sa connexion « Haut débit » :
Implanter une carte d’interface Ethernet dans le ou les clients PC. Connecter la carte
directement au modem xDSL ou sur un Hub Ethernet (dans le cas du partage de la
connexion).
Installer le driver Ethernet de la carte correspondant au système d’exploitation du
client
Installer le driver PPPoE qui fera le lien PPP entre le client et le modem xDSL.
Créer une connexion à un ISP de façon tout à fait classique.
Le résultat d’une demande de connexion est l’établissement d’une session PPP over
Ethernet. Le modem xDSL joue un rôle de pont MAC/LLC qui se contente de faire transiter du
flux PPP encapsulé dans des trames Ethernet d’un côté, vers du flux PPP circulant dans un
CVP ATM sur support xDSL de l’autre. Le CVP ATM défini permet la connexion directe à un
POP via la boucle locale « Haut débit ». Ce dernier doit être équipé de telle manière à
accepter des connexions PPP sur ce canal virtuel. L’ISP voit quand à lui arriver une demande
de connexion PPP des plus classiques. Lors du partage de connexion, il n’est pas nécessaire
de définir de CVP supplémentaires. En effet, le multiplexage de sessions PPP se réalise de
manière transparente.
Redback Networks est une des sociétés qui a activement participé à l’élaboration du
protocole PPPoE. Elle propose un équipement complet pour les POP s’appuyant sur un
serveur SMS1000.
Le schéma suivant résume une solution mettant en oeuvre PPPoE et le serveur de RedBack.
2.4 – Statut de PPP over Ethernet
Depuis son développement initial, PPPoE a été soumis en Août 1998 à l’IETF (Internet
Engineering Task Force) comme Internet Draft. Une session BOF (Birds Of a Feather) a
abouti à la mise à jour de l’Internet Draft initial.
Les sociétés qui ont participé à l’élaboration de PPPoE (RedBack Networks, UUNET,
Routerware) ont demandé à l’IETF d’inclure PPPoE dans les RFC (Request for Comment),
proposition qui a été retenue et qui fait référence à la RFC 2516
(http://www.frameip.com/rfc-2516-a-method-for-transmitting-ppp-over-ethernet-pppoe/).

3 – Le protocole PPP

3.1 – Introduction
Le protocole Point à Point (PPP) propose une méthode standard pour le transport de
datagrammes multi-protocoles sur une liaison simple point à point. PPP comprend trois
composants principaux :
Une méthode pour encapsuler les datagrammes de plusieurs protocoles.
Un protocole de contrôle du lien « Link Control Protocol » (LCP) destiné à établir,
configurer, et tester la liaison de données.
Une famille de protocoles de contrôle de réseau « Network Control Protocols »
(NCPs) pour l’établissement et la configuration de plusieurs protocoles de la couche
« réseau ».Dans notre cas nous n’utilisons que NCP/IP.
Nous présentons l’organisation et les méthodes utilisées par PPP, ainsi que l’encapsulation
effectuée par ce protocole, un mécanisme extensible de négociation d’options spécifique à
son utilisation capable de négocier une large gamme de paramètres de configuration et
apportant des fonctions étendues de gestion. Dans cette présentation Nous étudierons les
spécificités de son utilisation dans une cession de type PPPoE.

3.2 – Format de l’entête

La trame PPP est constituée d’un entête et d’un bloc de données. Cette encapsulation
nécessite l’usage d’un tramage dont le but principal est d’indiquer le début et la fin de
l’encapsulation. Les champs ci-dessous sont toujours transmis de gauche à droite.
 Flag – Indicateur de début ou fin de trame (Valeur = 01111110).
Adresse – Adresse de broadcast standard (Valeur = 11111111), car PPP n’attribue
pas d’adresse d’hôte (Couche 2 (http://www.frameip.com/osi/)).
Contrôle – Fourniture d’un service non orienté connexion (semblable au LLC) (Valeur
= 00000011).
Protocole – Identification du protocole encapsulé (LCP=Cxxx, NCP=8xxx,Protocole de
niveau 3=0xxx).
Code=8021 : IP
Code=8023 : OSI
Code=8025 : XNS, Vines
Code=8027 : DECnet
Code=8029 : AT
Code=8031 : Bridge
Données – Contient soit la valeur zéro, soit des données (1500 octets maximum).
FCS – Séquence de contrôle de trame pour une vérification des erreurs.

3.3 – Etablissement d’une connexion

Pour établir une connexion sur un lien Point à Point, chaque extrémité doit dans un premier
temps émettre des paquets LCP pour configurer et tester le support de liaison.
Ensuite, PPP envoie des paquets NCP pour choisir et configurer un ou plusieurs protocoles
réseau disponibles. Une fois ces protocoles configurés, les datagrammes peuvent être
envoyés sur la liaison. Celle-ci reste disponible jusqu’à ce que des paquets LCP ou NCP
spécifiques ne la ferment explicitement.

Dead – Une communication débute et se termine nécessairement dans cet état. Le

passage à la phase d’établissement s’effectue lorsque le niveau physique est prêt à
 accueillir la connexion.
Etablissement – Grâce au protocole LCP, les équipements distants s’échangent des
paquets de configuration par l’intermédiaire desquels ils négocient les paramètres
de la connexion. Au cours de cette phase, tout paquet non-LCP est ignoré.
Authentification – Par défaut, l’authentification n’est pas demandée mais sur
certaines liaisons, elle peut être indispensable. Dans ce cas, c’est lors de la phase
d’établissement que le protocole d’authentification doit être spécifié.
Connexion – le protocole réseau utilisé (IP, IPX ou Apple Talk) doit être configuré via
le protocole NCP. Le trafic sur le lien peut alors avoir lieu.
Fin – la fermeture de la liaison peut survenir suite à plusieurs événements comme la
perte de la porteuse, la chute d’une temporisation d’attente ou plus fréquemment
suite à la demande d’un utilisateur.
Voici un exemple appliqué dans le cadre d’une connexion d’un internaute à un provider:

3.4 – LCP – Link Control Protocol

LCP transporte les paquets permettant d’établir, de maintenir et de terminer PPP. Pour
l’établissement de PPP, il faut négocier de paramètres de fonctionnement. LCP gère les
options PPP indépendantes des protocoles de la couche réseau. Les premiers paquets
envoyés par les extrémités PPP négocient les options configurables au début d’une
connexion. Il existe trois classes de paquets LCP :
Les paquets de Configuration de Liaison utilisés pour établir et configurer une
communication (Requête-Configuration, Configuration-Acquittée, Configuration-
NonAcquittée et Configuration-Rejetée).
Les paquets de Fermeture de Liaison utilisés pour couper une communication
(Requête-Fermeture et Fermeture-Acquittée).
Les paquets de Maintenance de Liaison utilisés pour gérer et déterminer une liaison
(Code-Rejeté, Protocole-Rejeté, Requête-Echo, Réponse-Echo, et Requête-
Elimination).
Lorsque le champ Protocole du paquet PPP indique une valeur hexadécimale c021 (Link
Control Protocol). Format d’un paquet LCP :
 Code – Le champ Code comporte un octet, et identifie le type de paquet LCP.
Valeur=1 – Nom=Configure-Request : Départ de la connexion, définie et
négocie la configuration
Valeur=2 – Nom=Configure-Ack : Accusé de la réception d’un Configure-
Request
Valeur=3 – Nom=Configure-Nak : Réponse négative à la réception d’un
Configure-Request
Valeur=4 – Nom=Configure-Reject : Options de configurations non
reconnaissables
Valeur=5 – Nom=Terminate-Request : Fermeture de la connexion
Valeur=6 – Nom=Terminate-Ack : Accusé de la réception d’un Terminate-
Request
Valeur=7 – Nom=Code-Reject : Code reçu inconnu
Identificateur – Le champ Identificateur comporte un octet, et fournit un moyen
d’associer requêtes et réponses. Lorsqu’un paquet présente un Identificateur
invalide, il est ignoré sans affecter l’automate.
Longueur – Le champ Longueur comporte deux octets, et donne la longueur du
paquet LCP, y compris l’octet de Code, d’Identificateur, le champ Longueur lui-même
et le champ Données. La longueur ne doit pas excéder l’U R M de la liaison.
Données – Le champ Données comporte zéro ou un nombre quelconque d’octets,
selon l’indication du champ Longueur. Le format interne du champ Données dépend
de la valeur présente dans le champ Code.
Options de LCP pour PPPoE:
Recommandé : numéro magique, MRU (<=1492 Octets).
Non recommandé : Compression des champs (PFC).
Non utilisation : Vérification du séquencement des champs (FCS), Compression des
champs adresse et contrôle (ACFD); Table des caractères de contrôle asynchrones
(ACCM).

3.5 – NCP – Network Control Protocols

L’état réseau d’une connexion PPP suit soit l’état d’authentification, soit l’état
d’établissement. A ce stade, LCP a déjà établi toutes les options de PPP. La connexion est
active et presque prête à transporter les données de l’utilisateur. Le NCP configure les
protocoles de la couche réseau que la connexion PPP va transporter (IP pour PPPoE). Il
existe trois classes de paquets NCP :
Les paquets de Configuration, utilisés pour établir et configurer une communication
(Requête-Configuration, Configuration-Acquittée, Configuration-NonAcquittée et
Configuration-Rejetée).
Les paquets de Fermeture, utilisés pour couper une communication (Requête-
Fermeture et Fermeture-Acquittée).
Le paquet erreur (Code-Rejeté).
Détail du paquet NCP :

Code – Le champ Code comporte un octet, et identifie le type de paquet NCP.

Valeur=1 – Nom=Configure-Request : Départ de la connexion, définie et
négocie la configuration
Valeur=2 – Nom=Configure-Ack : Accusé de la réception d’un Configure-
Request
Valeur=3 – Nom=Configure-Nak : Réponse négative à la réception d’un
Configure-Request
Valeur=4 – Nom=Configure-Reject : Options de configurations non
reconnaissables
Valeur=5 – Nom=Terminate-Request : Fermeture de la connexion
Valeur=6 – Nom=Terminate-Ack : Accusé de la réception d’un Terminate-
Request
Valeur=7 – Nom=Code-Reject : Code reçu inconnu
Valeur=8 – Nom=Protocol-Reject : Réception avec une valeur de protocole
inconnu
Valeur=9 – Nom=Echo-Request : Loopback pour la détermination de la
qualité du lien
Valeur=10 – Nom=Echo-Reply : Réponse au Echo-Request
Valeur=11 – Nom=Discard-Request : Ignore la requête reçue
Identificateur – Le champ Identificateur comporte un octet, et fournit un moyen
d’associer requêtes et réponses. Lorsqu’un paquet présente un Identificateur
invalide, il est ignoré sans affecter l’automate.
Longueur – Le champ Longueur comporte deux octets, et donne la longueur du
paquet NCP.
Données – Le champ Données comporte zéro ou un nombre quelconque d’octets,
selon l’indication du champ Longueur. Le format interne du champ Données dépend
de la valeur présente dans le champ Code.

3.6 – Authentification
PPP peut supporter les opérations d’authentifications au début d’une connexion.
L’état d’authentification fait suite à l’état d’établissement si l’une ou l’autre des extrémités
est d’accord pour utiliser un protocole d’authentification. La négociation de cette option
s’effectue lors de la montée du niveau LCP. Les deux protocoles d’authentifications :
Password Authentication Protocol (PAP) – PAP implémente la méthode traditionnelle
avec l’utilisation d’un nom d’utilisateur et d’un mot de passe. Sur demande d’un
authentificateur , le récepteur répond avec le nom et le mot de passe,
l’authentificateur valide l’information et envoie un accusé de réception positif ou
négatif.
Challenge Handshake Authentification Protocol (CHAP) – CHAP implémente une
authentification utilisant un nom d’utilisateur et une chaîne aléatoire CHAP.
 L’authentificateur envoie son nom et sa chaîne aléatoire, le récepteur transforme
cette chaîne par un algorithme de calcul et une clé CHAP secrète. Il envoie ensuite le
résultat avec son propre nom, l’authentificateur compare la réponse avec sa propre
copie de la clé secrète. Enfin, il envoie un accusé de réception indiquant un échec ou
un succès.

4 – Le protocole PPPoE

4.1 – Introduction
Les technologies d’accès modernes font face à quelques problèmes et buts contradictoires.
Il est souhaitable de connecter des hôtes multiples à un site distant à travers un même
dispositif d’accès client. Un autre but est de fournir un contrôle d’accès et facturer selon la
même méthode que celle utilisée par PPP sur réseau commuté. Dans beaucoup de
technologies d’accès, la méthode la plus avantageuse financièrement pour rattacher des
hôtes multiples à un dispositif d’accès client est l’utilisation d’Ethernet. Enfin, la minimisation
des coûts est importante ; il faut utiliser la plus petite configuration possible ou mieux
aucune configuration.
PPP sur Ethernet (PPPoE) fournit la capacité de connecter un réseau d’hôtes vers un
concentrateur d’accès distant à travers un simple dispositif d’accès ponté. Avec ce modèle,
chaque hôte utilise sa propre pile PPP et l’utilisateur garde une interface familière. Le
contrôle d’accès, la facturation et les autres services peuvent être réalisés par un utilisateur
final plutôt que par un site final (la base).
Pour fournir une connexion point à point à travers Ethernet, chaque session PPP doit
apprendre l’adresse Ethernet de la machine distante afin d’établir et d’identifier une session
unique. PPPoE inclut donc un protocole de découverte.

4.2 – L’histoire
Ce document présente le protocole de communication baptisé PPPoE (Point to Point over
Ethernet) permettant de véhiculer du flux PPP (Point to Point Protocol) encapsulé dans des
trames Ethernet. Cette technologie (1998-99) est née d’un travail conjoint de UUNET
Technologies Inc., RedBack Networks Inc., et RouterWare Inc. Elle fait l’objet de la RFC 2516
(http://www.frameip.com/rfc-2516-a-method-for-transmitting-ppp-over-ethernet-pppoe/) qui
sera décrite au cours de l’étude du protocole PPPoE, suivi d’une traduction en français
(http://www.frameip.com/rfc-2516-fr-une-methode-pour-la-transmission-du-ppp-sur-
ethernet/).

4.3 – Format de l’entête

L’entête pour PPPoE se définie comme suit :

Version – 4 bits qui doivent être à la valeur 0x1 pour cette version de la spécification
PPPoE.
Type – 4 bits qui doivent être à la valeur 0x1 pour cette version de la spécification
 PPPoE.
Code – 8 bits définis plus bas pour l’étape de découverte et l’étape de la session
PPP.
Id – Valeur non signée sur 16 bits. C’est la valeur définie lors de l’étape de la
découverte. Cette valeur est fixée pour une session PPP donnée entre l’adresse
Ethernet source et l’adresse Ethernet destination. La valeur 0xffff est réservée pour
un usage futur et ne doit pas être utilisée.
Longueur – 16 bits indiquant la longueur de la charge utile PPPoE. Cela n’inclut pas
la longueur des entêtes Ethernet ou PPPoE.

Voilà comment l’entête Ethernet spécifie l’intégration de PPP

Adresse de destination – Ce champs, basé sur 6 octets contient soit une adresse
Ethernet unicast soit une broadcast (0xFFFFFFFFFFFF). Pour les paquets de
découverte, la valeur peux être soit unicast soit broadcast. Pour le trafic de session
PPP, ce champ doit contenir l’adresse unicast du peer distant qui a été déterminée
lors de l’étape Découverte.
Adresse source – Ce champs, basé sur 6 octets, doit contenir l’adresse MAC de
l’équipement source.
Type Ethernet – Ce champ codé sur 16 bits doit être configuré à 0x8863 pour l’étape
Découverte et 0x8864 pour la session PPP.
CRC – Ce champ permet en 4 octets de valider la conformité de la trame.

4.4 – Les étapes

PPPoE est composé de deux étapes distinctes : la découverte et la session PPP. Quand un
hôte veut initier une session PPPoE, il doit tout d’abord lancer une requête de découverte
afin d’identifier l’adresse Ethernet MAC de son vis à vis puis définir un identificateur de
session PPPoE. Alors que PPP définit une liaison de bout en bout, la phase de découverte
correspond à un rapport client-serveur. Lors du processus de découverte, un hôte (le client)
découvre un concentrateur d’accès (le serveur). Selon la topologie du réseau, il peut y avoir
plus d’un concentrateur d’accès avec lequel l’hôte peut communiquer. L’étape de la
découverte permet à l’hôte de découvrir tous les concentrateurs d’accès et d’en sélectionner
un. Quand la découverte s’achève avec succès, l’hôte et le concentrateur d’accès sélectionné
possèdent les informations qu’ils emploieront pour construire leur connexion point à point
sur Ethernet.
L’étape de la découverte attend alors jusqu’à ce qu’une session PPP soit établie. Une fois
qu’une session PPP est établie, l’hôte et le concentrateur d’accès doivent allouer les
ressources pour une interface virtuelle PPP.

4.4.1 – Découverte
L’étape de découverte s’effectue en quatre temps. Quand elle s’achève, chaque vis à vis
connaît l’identificateur de session PPPoE ainsi que les adresses Ethernet des extrémités;
cela suffit pour définir une session PPPoE. Les étapes sont :
Emission par diffusion d’un paquet d’initialisation par l’hôte.
 Emission de paquets d’offres par un ou plusieurs concentrateurs d’accès.
Emission adressée d’un paquet de demande de session par l’hôte.
Emission d’un paquet de confirmation par le concentrateur d’accès sélectionné.

Quand l’hôte reçoit le paquet de confirmation, il peut passer à l’étape suivante : la session
PPP. Toutes les trames de découvertes Ethernet ont la valeur 0x8863 dans le champ « Type
Ethernet ». La charge utile PPPoE contient zéro ou plusieurs TAGs. Un TAG est un ensemble
type-longueur-valeur (TLV) construit et défini comme suit :
Type – 16 bits. L’annexe A contient une liste de tous les types et de leurs valeurs.
Longueur – Valeur non-signée sur 16 bits indiquant en octets la longueur de «
Valeur ».

Si un paquet de découverte est reçu avec un TAG de type inconnu, il doit être ignoré à moins
qu’il n’en soit spécifié autrement dans ce document. Ceci fournira une compatibilité
ascendante lorsque de nouveaux TAGs seront ajoutés. Lorsque de nouveaux TAGs
indispensables seront ajoutés, le numéro de version sera incrémenté.
Voici un exemple appliqué dans le cadre de l’ADSL. En effet lors de connexion PPPoE, le client
pourra choisir l’équipement de connexion pour soit aller vers son provider, soit vers un
serveur multicast ou établir deux sessions simultanées.

Le paquet de découverte « Initialisation » (PADI)

Les hôtes envoient le paquet PADI (PPPoE Active Discovery Initition) en plaçant l’adresse de
diffusion dans le champ « Adresse de destination ». Le champ « Code » contient 0x09 et le
champ « Identificateur de session » contient 0x0000. Le paquet PADI doit contenir un TAG
de type « Nom du service » indiquant le service que l’hôte demande ainsi qu’un nombre
quelconque de TAGs d’autres types. Un paquet PADI entier (incluant l’entête PPPoE) ne doit
pas dépasser 1484 octets afin de laisser la place suffisante pour qu’un agent relais puissent
ajouter un TAG « Identificateur de session relais ».
Le paquet de découverte « Offre » (PADO)
Quand le concentrateur d’accès reçoit un PADI qu’il peut servir, il répond en envoyant un
paquet PADO (PPPoE Active Discovery Offer). L’adresse de destination est l’adresse de l’hôte
telle qu’envoyée dans le PADI. Le champ « Code » est fixé à 0x07 et le champ «
Identificateur de session » à 0x0000. Le paquet PADO doit contenir exactement un TAG «
Concentrateur d’accès-Nom » contenant le nom du concentrateur d’accès, un TAG « Nom du
service » identique à celui contenu dans le PADI et un nombre quelconque d’autres TAGs «
Nom du service » indiquant les autres services offerts par le concentrateur d’accès. Si le
concentrateur d’accès ne peut pas servir le PADI, il ne doit pas répondre avec un PADO.

Le paquet de découverte « Requête » (PADR)

Puisque le PADI a été envoyé en diffusion, l’hôte peut recevoir plusieurs PADO. L’hôte
examine les paquets PADO reçus et en choisit un. Le choix peut être basé sur le nom du
concentrateur d’accès ou sur les services offerts. L’hôte envoie alors un paquet PADR (PPPoE
Active Discovery Request) au concentrateur d’accès sélectionné. Le champ « Adresse de
destination » est l’adresse Ethernet du concentrateur d’accès qui a été envoyée par le
PADO. Le champ « Code » contient 0x19 et le champ « Identificateur de session » la valeur
0x0000. Le paquet PADR doit contenir exactement un TAG de type « Nom du service »
indiquant le nom du service que l’hôte a demandé et un nombre quelconque de TAGs
d’autres types.
Le paquet de découverte « Confirmation de session » (PADS)
Quand le concentrateur d’accès reçoit un paquet PADR, il se prépare à commencer une
session PPP. Il génère un identificateur de session unique pour la session PPPoE et répond
à l’hôte avec un paquet PADS (PPPoE Active Discovery Session-confirmation). Le champ «
Adresse de destination » est l’adresse Ethernet de l’hôte qui a envoyé le PADR. Le champ «
Code » contient 0x65 et le champ « Identificateur de session » doit être mis à la valeur
unique générée pour cette session PPPOE. Le paquet PADS contient exactement un TAG de
type « Nom du service » indiquant le nom du service sous lequel le concentrateur d’accès a
accepté la session PPPoE et un nombre quelconque de TAGs d’autres types. Si le
concentrateur d’accès n’accepte pas le service proposé dans le PADR, il doit répondre avec
un PADS contenant un TAG de type « Nom du service-Erreur ». (et un nombre quelconque de
TAGs d’autres types). Dans ce cas le champ « Identificateur de session » doit contenir
0x0000.

Le paquet de découverte « Terminaison » (PADT)

Ce paquet peut être envoyé à n’importe quel moment après qu’une session ait été établie
pour indiquer que la session PPPoE est terminée. Il peut être envoyé soit par l’hôte, soit par
le concentrateur d’accès. Le champ « Adresse de destination » est une adresse Ethernet
fixée, le champ « Code » contient 0xa7 et le champ « Identificateur de session » doit
indiquer quelle session se termine. Aucun TAG n’est nécessaire. Quand un paquet PADT
(PPPoE Active Discovery Terminate) est reçu, aucun autre trafic PPP utilisant cette session ne
peut être envoyé. Même les paquets normalement utilisés pour terminer une session PPP ne
doivent pas être envoyés après réception d’un PADT. Une extrémité PPP devrait utiliser le
protocole PPP lui-même pour arrêter une session PPPoE, mais le paquet PADT peut être
utilisé quand PPP ne le peut pas.

4.4.2 – Session PPP

Une fois que la session PPPoE est ouverte, les données PPP sont envoyées comme dans
n’importe quelle autre encapsulation PPP. Tous les paquets Ethernet contiennent une
adresse fixe. Le champ « Type Ethernet » vaut 0x8864. Le champ « Code » de PPPoE doit
contenir 0x00. Le champ « Identificateur de session » ne doit pas changer pour cette
session PPPoE et doit être à la même valeur que celle assignée lors de l’étape de
découverte. La charge utile PPPoE contient une trame PPP. La trame commence avec
l’identificateur de protocole de PPP.

Quand un hôte ne reçoit pas de paquet PADO au bout d’un laps de temps déterminé, il doit
renvoyer le paquet PADI et doubler la période d’attente. Cela peut se répéter autant de fois
que souhaité et désiré. Si l’hôte attend pour recevoir un paquet PADS, un mécanisme
similaire de temps mort doit être employé, avec l’hôte renvoyant le PADR. Après un nombre
déterminé d’essais, l’hôte doit alors renvoyer un paquet PADI. Les valeurs du champ « Type
Ethernet » employées dans ce document (0x8863 et 0x8864) ont été assignées par l’IEEE
pour l’utilisation de PPPoE. L’utilisation de ces valeurs et le champ « Version » sont les seuls
identifiants du protocole.

4.5 – Sécurité
Afin de se protéger contre d’éventuels actes de piratage, le point d’accès (AC : Access
Concentrator) peut utiliser le TAG AC-Cookie. Ce dernier doit être en effet capable de
générer de manière unique une valeur de TAG basée sur l’adresse MAC source d’une
requête PADR, identifiant l’hôte émetteur. Cet identifiant permettra ainsi au point d’accès de
limiter le nombre de sessions simultanées pour un hôte donné. L’algorithme utilisé pour la
génération d’un identifiant unique à partir de l’adresse MAC est laissé au choix des
constructeurs (détail d’implémentation). L’algorithme HMAC (Keyed-Hashing for Message
Authentication) peut par exemple être mis en place. Il nécessite une clé privée qui n’est
connue que du point d’accès. Attention toutefois à l’utilisation du TAG AC-Cookie, car il est
une méthode de protection contre certaines attaques, mais il n’offre pas une garantie de
sécurité totale.
Certains point d’accès ne souhaitent pas forcément diffuser l’ensemble des services qu’ils
implémentent à des hôtes non authentifiés. Dans ce cas, deux stratégies peuvent être
employées :
Ne jamais refuser une requête basée sur le TAG Service-Name, et toujours lui
retourner la valeur du service demandé. Il y a donc correspondance entre le service
demandé et le service retourné à l’hôte émetteur.
N’accepter que les requêtes Service-Name ayant une longueur de TAG nulle
(indiquant n’importe quel service). L’hôte émetteur et le point d’accès connaissent
déjà le type de service utilisé pour cette session. L’information sur le service ne
circule donc plus sur le réseau.

5 – Le protocole L2TP

5.1 – Introduction
L2TP a été conçu pour transporter des sessions PPP au travers d’un réseau IP, et de
terminer physiquement les sessions PPP en un point de concentration déterminé dans le
réseau.
Le protocole L2TP (Layer 2 Tunneling Protocol), développé à partir du protocole point à point
PPP, est sans conteste l’une des pierres angulaires des réseaux privés virtuels d’accès. Il
rassemble en effet les avantages de deux autres protocoles L2F et PPTP. L2TP est une
norme préliminaire de l’IETF (Engineering Task Force) actuellement développée et évaluée
conjointement par Cisco Systems, Microsoft, Ascend, 3Com et d’autres acteurs clés du
marché des réseaux.
Le protocole L2TP est un protocole réseau qui encapsule des trames PPP pour les envoyer
sur des réseaux IP, X25, relais de trames ou ATM. Lorsqu’il est configuré pour transporter les
données sur IP, le protocole L2TP peut être utilisé pour faire du tunnelling sur Internet. Dans
ce cas, le protocole L2TP transporte des trames PPP dans des paquets IP. La maintenance
du tunnel est assurée à l’aide de messages de commandes au format L2TP tandis que
le protocole UDP (http://www.frameip.com/entete-udp/) est utilisé pour envoyer les trames
PPP au sein de trames L2TP.

5.2 – Format de l’entête

T – 1 bit indiquant le type de message. 0 si c’est un message de données, 1 si c’est

un message de contrôle.
L – 1 bit qui positionné à 1, indique la présence du champ longueur. Ce bit doit être
mis à 1 dans les messages de contrôle.
0 – 2 bits réservés pour des extensions futures. Pour l’instant ces bits sont mis à 0
 et ignorés.
S – 1 bit qui positionné à 1 indique la présence des champs Ns et Nr. Ce bit doit être
à 1 dans les messages de contrôle.
0 – 1 bit réservé pour des extensions futures. Pour l’instant ce bit est mis à 0 et
ignoré.
O – 1 bit qui positionné à 1, indique la présence du champ Offset Size. Ce bit doit
être à 0 pour les messages de contrôle.
P – 1 bit qui positionné à 1, considère ce message comme prioritaire. Exemple :
messages LCP echo request utilisés par les extrémités PPP pour le maintien de la
session PPP.
0 – 4 bits réservés pour des extensions futures. Pour l’instant ces bits sont mis à 0
et ignorés.
Version – 4 bits indique la version du tunnel employé. Il doit être à 2 pour le L2TP
RFC 2661. La valeur 1 représenterait un paquets L2F.
Longueur – 16 bits. Ce champ est optionnel et représente la longueur totale du
message en octet. Ce champ n’existe que si le flag L est positionné à 1.
Tunnel ID – 16 bits représentant l’identifiant du tunnel, qui a une signification locale.
Le Tunnel ID d’un message est celui du destinataire.
Session ID – 16 bits représentant l’identification pour une session dans un tunnel.
La signification est également purement locale. La session ID d’un message est celui
du destinataire.
Ns – 16 bits correspondant au numéro de séquence pour ce message.
Nr – 16 bits correspondant au numéro de séquence attendu lors de la réception du
prochain message.
Offset Size – 16 bits représentant la longueur de la fin de l’entête L2TP.

5.3 – Les concentrateurs d’accès – LAC

Les concentrateurs d’accès L2TP, signifiant L2TP Access Concentrateur (LAC), peuvent être
intégrés à la structure d’un réseau commuté comme le réseau téléphonique commuté (RTC)
ou encore associés à un système d’extrémité PPP prenant en charge le protocole L2TP.
Le rôle du concentrateur d’accès LAC se limite à fournir un support physique qui sera utilisé
par L2TP pour transférer le trafic vers un ou plusieurs serveurs réseau L2TP (LNS). Il assure
le fractionnement en canaux pour tout protocole basé sur PPP. Le concentrateur d’accès LAC
joue le rôle de serveur d’accès, il est à l’origine du tunnel et est responsable de
l’identification du VPN.

5.4 – Les serveurs réseau – LNS

Les serveurs réseau L2TP, signifiant L2tp Network Server (LNS), peuvent fonctionner sur
toute plate-forme prenant en charge la terminaison PPP. Les serveurs réseaux L2TP gèrent
le protocole L2TP côté serveur. Les serveurs LNS sont les émetteurs des appels sortants et
les destinataires des appels entrants. Ils sont responsables de l’authentification du tunnel.

5.5 – Avantages et inconvénients

L2TP repose sur UDP qui lui même repose sur IP. Au total, l’empilement total des couches
protocolaires est le suivant (en partant du backbone) : IP/PPP/L2TP/UDP/IP/Couche2. A cela
se rajoutent TCP/HTTP si l’utilisateur surfe sur le web. L’ensemble n’est donc pas très léger,
et une attention particulière doit être portée sur ce qui est de l’accordement de MRU (pour
PPP) avec la MTU de tous les équipements IP traversés, de telle façon à éliminer la
fragmentation sur les paquets de grande taille. L’overhead représente donc l’inconvénient
de L2TP.
L2TP permettant de terminer des sessions PPP n’importe où. Cela permet à un opérateur ou
plus généralement au propriétaire d’un réseau d’accès (boucle locale) de collecter pour le
compte d’un tiers des connexions et de lui laisser le soin de terminer les sessions PPP
associées. C’est vraiment la fonction VPN de L2TP : permettre à un utilisateur mobile de se
connecter à un réseau particulier, éventuellement privé, tout en utilisant une infrastructure
publique et partagée. Ainsi un salarié d’une entreprise peut être sûr de se connecter à un
VPN particulier de son entreprise (http://www.frameip.com/vpn/) (correspondant à son
groupe de travail), quelque soit le POP de son entreprise auquel il se connecte. Il peut ainsi
conserver les droits, et les restrictions définies par son profil. Les concepts de mobilité et de
Wholesale représentent donc les avantages de L2TP.

6 – L’architecture PPP – L2TP

6 – L’architecture PPP – L2TP

6.1 – Architecture IP
Voici l’architecture PPP transporté sur un réseau d’infrastructure IP via L2TP :

Un détail important lors du paramétrage d’un Firewall (http://www.frameip.com/firewall/) : le

L2TP encapsulé dans UDP utilise le port 1701 (http://www.frameip.com/liste-des-ports-tcp-
udp/)

6.2 – Les encapsulations

Voici un exemple dans le cas où le client surf via le protocole HTTP.

6.2.1 – Cas de PPP

6.2.1 – Cas de PPPoE

6.2.1 – Cas de L2TP

6.3 – Les tailles maximums de l’OverHead
6.3.1 – Cas de PPP
OverHead = PPP
La surcouche des entêtes est donc de 8 octets. Voici la représentation en pourcentage dans
le cadre de paquet non fragmenté :
Taille de datagramme = 0070 : Pourcentage relatif = 11,4%
Taille de datagramme = 1300 : Pourcentage relatif = 00,6%
Taille de datagramme = 1500 : Pourcentage relatif = 00,5%

6.3.2 – Cas de PPPoE

OverHead = PPP + PPPoE
La surcouche des entêtes est donc de 8+6=14 octets. Voici la représentation en
pourcentage dans le cadre de paquet non fragmenté :
Taille de datagramme = 0070 : Pourcentage relatif = 20,0%
Taille de datagramme = 1300 : Pourcentage relatif = 01,1%
Taille de datagramme = 1500 : Pourcentage relatif = 00,9%

6.3.2 – Cas de L2TP

OverHead = PPP + L2TP + UDP + IP
La surcouche des entêtes est donc de 8+6+8+20=42 octets. Voici la représentation en
pourcentage dans le cadre de paquet non fragmenté :
Taille de datagramme = 0070 : Pourcentage relatif = 60,0%
Taille de datagramme = 1300 : Pourcentage relatif = 03,2%
Taille de datagramme = 1500 : Pourcentage relatif = 02,8%

6.4 – Problématique liée au MTU

Si l’infrastructure de l’opérateur est basée sur Ethernet, alors un Overhead de 42 octets
demande une gestion de trame Ethernet de 1518+42 soit 1560 octets pour ne pas
fragmenter. Je ne compte pas en plus si cette infrastructure Ethernet gère les VLAN.
L’utilisation de la VOIP (http://www.frameip.com/voip/) devient dans ce cadre assez difficile à
maîtriser.

7 – Conclusion
L2TP permet en conclusion le transport d’une couche 2 (PPP) over un réseau d’infrastructure
basé sur IP. Cela permet aux opérateurs de véhiculer des services étanches basés sur une
authentification Radius apportant un provisionning simple, dynamique et rapide. L’intérêt
d’une séparation du réseau d’infrastructure des services devient évidente.
Les réseaux, y compris ceux d’infrastructures opérateurs, évoluent vers du full IP. Les
services existants et futurs sont réalisés par des concepts de L3VPN et L2VPN. Ceci
permettant de répondre aussi aux exigences d’interconnexions Lan to Lan. L2TP se
positionne comme un tunnel transportant un L2 over IP, d’autres apparaissent sur le marché
comme VPLS, VPWS, PWE3 et comme le dit Cisco, l’ATOM (Any transport Over MPLS
(http://www.frameip.com/mpls-cisco/)).

8 – Suivi du document
Création et suivi de la documentation par _SebF – Merci à Emmanuel Hulin et Philippe
Masquart

9 – Discussion autour de l’Architecture L2TP – Layer 2

Tunneling Protocol
Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos
expériences à propos de l’Architecture L2TP – Layer 2 Tunneling Protocol. Pour cela,
n’hésitez pas à laisser un commentaire ci-dessous :

Commentaire et discussion