PPPoE
Comme vu dans les articles sur PPP (première partie, deuxième partie), ce dernier a été conçu pour fonctionner sur des liens de nature point-à-point, liens pouvant être physiques (L1—par exemple, lien série classique ou lien série SONET/SDH) ou logiques (L2—par exemple, lien Frame Relay, ISDN ou ATM). Si les protocoles L2 cités en exemple ci-avant peuvent être configurés en point-à-point nativement, ce n'est pas le cas d'Ethernet qui est de nature multipoint. Aussi, PPP ne peut pas être encapsulé directement dans Ethernet et une couche d'adaptation intermédiaire, qui va simuler un lien L2 point-à-point (appelé « session »), doit être introduite. Cette couche, définie dans la RFC 2516, se nomme sans surprise PPPoE (PPP over Ethernet) et fonctionne en plusieurs étapes :
| Étape | Description | Exemple pratique |
|---|---|---|
PADI |
Le client PPPoE (appelé Host dans la RFC) recherche son pair, c'est-à-dire le serveur PPPoE (appelé Access Concentrator dans la RFC), via une trame broadcast. | La box d'un abonné Internet recherche un BAS du FAI. |
PADO |
Le ou les (pour des besoins de redondance) serveurs PPPoE présents sur le réseau Ethernet répondent au client PPPoE via une trame unicast. | Le ou les BAS du FAI répondent à la box de l'abonné Internet. |
PADR |
Le client PPPoE choisit un serveur PPPoE (critères de choix variables : celui qui a répondu le plus vite, selon le nom, etc.) et demande l'établissement de la session via une trame unicast. | La box de l'abonné Internet choisit l'un des BAS du FAI. |
PADS |
Le serveur PPPoE indique au client PPPoE que la session PPPoE est maintenant établie via une trame unicast
(qui contient notamment le SESSION_ID). |
Le BAS choisi indique à la box de l'abonné Internet que la session PPPoE est maintenant établie. |
— |
À partir de là, le lien PPP peut être établi dans la session PPPoE (comme illustré dans l'article précédent). | La box d'un abonné Internet émet et reçoit du trafic Internet. |
PADT |
Enfin, une fois le lien PPP rompu, le client PPPoE ou le serveur PPPoE demande la fermeture de la session PPPoE. | La box d'un abonné Internet vient d'être éteinte ou le lien physique entre la box et le FAI vient d'être rompu. |
Noter que la RFC distingue deux phases : PPPoED (PPPoE Discovery) qui comprend les étapes un à quatre ainsi que la dernière (c'est-à-dire, l'établissement et la fermeture de la session PPPoE) et PPPoES (PPPoE Session) qui comprend l'étape cinq uniquement (c'est-à-dire, la session PPPoE proprement dite). Nous allons retrouver ces termes courants dans la capture réseau.
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK et DHCPRELEASE.
Voici une capture de PPPoE avec le lien PPP qui s'ensuit :
| R1 (client PPPoE) | R2 (serveur PPPoE) |
|---|---|
|
|
PADI, PADO, PADR et PADS
qui ont permis d'établir la session PPPoE dans laquelle peut être établi le lien PPP.
Nous retrouvons ainsi le même PPP que dans l'article précédent mais encapsulé sur Ethernet.
Dialer chez Cisco) sont souvent adressées en /32
et un réseau d'interconnexion en /30 par exemple n'est pas nécessaire (même si utilisé dans l'exemple ci-dessus).
Nous pouvons voir les différentes sessions PPPoE établies sur le serveur PPPoE (une seule ici) via la commande suivante :
R2#show pppoe session
1 session in LOCALLY_TERMINATED (PTA) State
1 session total
Uniq ID PPPoE RemMAC Port Source VA State
SID LocMAC VA-st
1 1 c001.1b74.0000 Fa0/0 Vt1 Vi1.1 PTA
c002.27f0.0000 UP
Nous pouvons aussi depuis le serveur PPPoE fermer la session PPPoE, ce qui permet de jouer les échanges liés à la fermeture :
R2#clear pppoe rmac c001.1b74.0000
Terminate de PPP avant l'étape PADT de PPPoE.
La raison de la IP MTU (appelée PPP MRU) fixée à 1492 octets se comprend vite avec un schéma. Sur une transmission classique TCP/IP sur Ethernet (RFC 894), nous avons ceci :
6 octets 6 octets 2 octets 20 octets 20 octets 1460 octets 4 octets
+----------+----------+----------+-----------+------------+-------------+----------+
| DA | SA | Len/Type | IP Header | TCP Header | TCP Data | FCS |
+----------+----------+----------+-----------+------------+-------------+----------+
<------------ 1500 octets ------------>
Or, sur une transmission TCP/IP sur PPPoE, huit octets de plus doivent être intégrés à la trame Ethernet sans pour autant agrandir sa taille :
6 octets 6 octets 2 octets 6 octets 2 octets 20 octets 20 octets 1452 octets 4 octets
+----------+----------+----------+----------+----------+-----------+------------+-------------+----------+
| DA | SA | Len/Type | PPPoES | PPP | IP Header | TCP Header | TCP Data | FCS |
+----------+----------+----------+----------+----------+-----------+------------+-------------+----------+
<------------ 1492 octets ------------>
<----------------------- 1500 octets ----------------------->
Ces huit octets sont alors impactés sur la taille de la IP MTU ainsi que la taille de la TCP MSS.
Noter que le client PPPoE (typiquement, une box d'un abonné Internet) n'émet pas de segment TCP—ou
alors, lorsqu'elle est supervisée à distance.
C'est surtout l'équipement de l'utilisateur final (typiquement, un ordinateur fixe ou portable) qui en émet dans le cadre de son trafic Internet.
La commande liée à la TCP MSS permet de modifier « à la volée » celle annoncée par l'équipement de l'utilisateur final
(dans les segments SYN)
qui reste, elle, configurée à 1460 octets par défaut.
Pourquoi PPPoEoVLAN ?
Cette appellation signifie juste qu'il y a un VLAN présent dans les trames Ethernet encapsulant PPPoE. La motivation est celle même des VLAN : en segmentant le domaine de diffusion L2, ils apportent sécurité et performance. Dans un contexte PPPoE, prenons l'exemple d'un opérateur qui agrège sur un même switch Ethernet le trafic de ses clients professionnels et résidentiels. À l'évidence, séparer leur trafic avec des VLAN distincts est une bonne pratique.
Pourquoi PPPoEoA ?
Cette appellation signifie que la trame Ethernet encapsulant PPPoE est transportée dans ATM. Ce n'est pas PPPoE seul qui est transporté mais bien la trame Ethernet entière. De plus, ce n'est pas un protocole à proprement parler mais une méthode d'encapsulation décrite dans la RFC 2684 qui ne concerne pas qu'Ethernet mais aussi IP par exemple (précurseur de MPLS).