Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
Protocol
Par _SebF
1 - Introduction
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 - Discussion autour de la documentation
9 - Suivi du document
1 - Introduction
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, 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, 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).
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 !
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.
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.
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.
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.
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 : translation d'adresses IP d'un
réseau vers un autre) et 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.
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
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.
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 PPPoE qui fera le lien PPP entre le client et le modem xDSL.
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.
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:
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 en-tê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.
Adresse - Adresse de broadcast standard (Valeur = 11111111), car PPP n'attribue pas
d'adresse d'hôte (Couche 2).
Contrôle - Fourniture d'un service non orienté connexion (semblable au LLC) (Valeur =
00000011).
Code Protocole
8021 IP
8023 OSI
8025 XNS, Vines
8027 DECnet
8029 AT
8031 Bridge
Données - Contient soit la valeur zéro, soit des données (1500 octets maximum).
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:
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.
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.
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).
Longueur - Le champ Longueur comporte deux octets, et donne la longueur du paquet NCP.
3.6 - Authentification
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 :
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
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 en-tê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.
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 :
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.
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.