PPP

Rapport de
téléinformatique
Le protocole PPP
Auteur : Jann Daniel, Ramqaj Visar

Professeur : Schaefer Marc, Tièche François
Classe : INF 3
Le Locle, le 15 avril 2005

Le protocole PPP Téléinformatique
Table des matières

Table des matières ___________________________________________________ 2
Terminologie________________________________________________________ 4
Introduction ________________________________________________________ 5
Slip 5
PPP 5
1. Encapsulation PPP ________________________________________________ 6
1.1 Le champ protocole ______________________________________________ 6
1.2 Le champ Information ____________________________________________ 7
1.3 Le champ bourrage ______________________________________________ 7
2. Fonctionnement___________________________________________________ 7
2.1 Etape 1 : établissement de la liaison___________________________________ 7
2.2 Etape 2 : authentification (optionnel) __________________________________ 7
2.3 Etape 3 : configuration des NP par les NCP _____________________________ 7
3. Diagramme d’état _________________________________________________ 8
3.1 Phase de liaison morte ____________________________________________ 9
3.2 Phase d’établissement de liaison _____________________________________ 9
3.3 Phase d’authentification ___________________________________________ 9
3.4 Phase de négociation réseau ________________________________________ 9
3.5 Phase de fermeture de liaison _______________________________________ 9
4. Tramage de données PPP avec des trames comme-HDLC
(rfc 1662 – « HDLC-like frames ») ____________________________________ 11
4.1 Format des trames ______________________________________________ 11
4.1.1 Les champs Drapeau _______________________________________ 11
4.1.2 Le champ Adresse_________________________________________ 11
4.1.3 Le champ Contrôle ________________________________________ 11
4.1.4 Le champ FCS ___________________________________________ 11
4.2 Le problème de la transparence _____________________________________ 11
4.2.1 Tramage à octet de bourrage (pour les liens asynchrones 8 bits et
synchrones octets)_________________________________________ 12
4.2.2 Tramage par bit de bourrage (pour les liens synchrones orientés bit) _____ 12
5. Les protocoles NCP _______________________________________________ 13
6. Le protocole LCP (rfc 1661)_________________________________________ 15
6.1 Format des paquets LCP __________________________________________ 15
6.1.1 Le champ Code___________________________________________ 15
6.1.2 Le champ identifier ________________________________________ 16
Jann Daniel Page 2 sur 26 Le Locle, le 15 avril 2005

Ramqaj Visar
6.1.3 Le champ Longueur _______________________________________ 16
6.1.4 Le champ données_________________________________________ 16
6.2 Types de paquets LCP ___________________________________________ 16
6.2.1 Code 0 : Vendor Specific (rfc 2153) ____________________________ 16
6.2.2 Code 1 : Configure-Request (demande de config. d’options) ___________ 16
6.2.3 Code 2 : Configure-Ack (Acceptation de la modification d’options) _____ 16
6.2.4 Code 3 : Configure-Nak (Non-acceptation de la modification
d’options)_______________________________________________ 17
6.2.5 Code 4 : Configure-Reject (Rejet définitif de certaines options)_________ 17
6.2.6 Code 5 et 6 : Terminate-Request et Terminate-ack (Fermeture de la
connexion) ______________________________________________ 17
6.2.7 Code 7 : Code-Reject ______________________________________ 17
6.2.8 Code 8 : Protocol-Reject ____________________________________ 18
6.2.9 Code 9 et 10 : Echo-Request et Echo-Reply_______________________ 18
6.2.10 Code 11 : Discard-Request___________________________________ 18
6.2.11 Code 12 : Identification (rfc 1570) _____________________________ 19
6.2.12 Code 13 : Time-Remaining (rfc 1570)___________________________ 19
6.3 Format des options des paquets LCP _________________________________ 19
6.3.1 Format général des options __________________________________ 20
6.3.2 Champ Type _____________________________________________ 20
6.3.3 Champ longueur __________________________________________ 21
6.4 Les options de base des paquets LCP _________________________________ 21
6.4.1 Code 1 : MRU Maximum Receive Unit__________________________ 21
6.4.2 Code 3 : Authentification Protocol _____________________________ 21
6.4.3 Code 4 : Quality Protocol____________________________________ 21
6.4.4 Code 5 : Nombres magiques__________________________________ 22
6.4.5 Code 7 : Protocol Field Compression ___________________________ 22
6.4.6 Code 8 : Address and Control Field Compression (ACFC) ____________ 23
7. Décodage d’une trame PPP _________________________________________ 24
7.1 La trame PPP__________________________________________________ 24
7.2 Détrammage __________________________________________________ 24
7.3 Décodage LCP ________________________________________________ 24
7.4 Décodage des options____________________________________________ 24
8. Conclusion______________________________________________________ 25
9. Bibliographie____________________________________________________ 26
9.1 Liens Internet _________________________________________________ 26

Ramqaj Visar
Terminologie
Liaison point à point
C’est une communication par modem entre deux ordinateurs maximums, de la même manière
qu’une personne ne peut pas joindre deux autres personnes simultanément sur la même ligne
téléphonique.
Datagramme
C’est l'unité de transmission de la couche réseau (par exemple IP). Un datagramme peut être
encapsulé dans un ou plusieurs paquets passés à la couche liaison.
Trame
C’est l'unité de transmission de la couche liaison. Une trame peut comporter un en-tête et/ou
une queue, et des octets de données.
Paquet
C’est l'unité d'encapsulation de base, passant entre la couche réseau et la couche liaison de
données. Un paquet est en général associé à une trame; sauf pour les cas particuliers où une
fragmentation du paquet doit être opérée, où lorsque plusieurs paquets sont insérés dans une
trame unique.
Acronymes :
PPP : Point to Point Protocol (protocole point à point)
NP : Network Protocols (protocoles de couche réseau)
NCP : Network Control Protocols (Protocoles de contrôles de la couche réseau)
LCP : un protocole en particulier parmi les Link Control Protocols

Ramqaj Visar
Introduction
Le protocole PPP (Point to Point Protocol qui se traduit par Protocole Point à Point) est un
protocole de liaison de données qui assure un échange fiable des données sur une liaison point
à point.
Le protocole PPP a été crée pour résoudre les problèmes d’un ancien protocole nommé SLIP
(Serial Line Internet Protocol, qui veut dire protocole Internet de liaison en série).
Slip
Ce protocole n’effectue aucun contrôle d’adresse ni aucun contrôle d’erreur. La transmission
des données est assez simple, on envoie une simple trame qui contient uniquement un
caractère de fin de transmission qui est le END (192 en code ASCII).
Voici le format d’une trame SLIP :
Données à transmettre END
Figure 1 : format d’une trame SLIP
PPP
Le protocole PPP est plus complexe que le protocole SLIP. Il transfère sur une trame des
données supplémentaires qui sont mieux adaptés à la transmission de données sur l’Internet.
Ce protocole est en fait un ensemble de protocole :
• Un protocole d’encapsulation des datagrammes,
• Un protocole de contrôle de liaison (Link Control Protocol) qui permet de faire des
tests et de vérifier la configuration de la communication,
• Un ensemble de protocole de contrôle (Network Control Protocol) qui permet de
lancer et configurer différent protocole de la couche réseaux.
Figure 1 : établissement d’une connexion PPP

Les données à transmettre sont encapsulés dans des paquets, qui sont en fait des datagrammes.

Ramqaj Visar
1. Encapsulation PPP
PPP permet d’utiliser plusieurs protocoles de couche réseau. Pour ce faire, on utilise
l’encapsulation PPP : Un paquet PPP contient d’abord un identifiant correspondant au
protocole encapsulé, le datagramme du protocole encapsulé, puis éventuellement des octets de
bourrage :
Protocole (8 ou 16 bits) Information Bourrage
Figure 2 : format d’un paquet PPP
1.1 Le champ protocole

De longueur 1 ou 2 octets, ce champ identifie le protocole utilisé dans le champ Information.
L’identifiant est toujours impair, de plus le premier octet doit toujours être pair, ceci pour
permettre la compression de protocoles (6.4.5 Protocol Field Compression). Exemples : 02A3
; 02A2 ; 01A3
Les identifiants sont répartis en plusieurs plages :
0000 à 3FFF : protocoles de la couche réseau (NP)
4000 à 7FFF : protocoles de faible trafic ne disposant pas de NCP associés
8000 à BFFF : protocoles NCP associés aux NP
C000 à FFFF : Link Control Protocols (p. ex LCP)
Exemples1 :
NP
0021 : IPv4
0029 : AppleTalk
002B : Novell IPX
NCP
8021 : Internet Protocol Control Protocol (IPCP)
8029 : AppleTalk Control Protocol
802B : Novell IPX Control Protocol
Link Control Protocols
C021 : Link Control Protocol (LCP)
C023 : Password Authentification Protocol (PAP)
C223 : Challenge Handshake Authentification Protocol (CHAP)
1
La liste complète des identifiants est disponible sur http://www.iana.org/assignments/ppp-numbers

Ramqaj Visar
1.2 Le champ Information

Il contient les datagrammes du protocole spécifié dans le champ protocole.
La longueur cumulée du champ d’information et de bourrage peut atteindre au maximum
l’unité de réception maximale (URM) qui est par défaut 1500 octets. L’URM peut être
modifiée grâce au protocole LCP.
1.3 Le champ bourrage

Le champ information peut être complété par un nombre arbitraire d’octets de bourrage (tant
que l’URM est respectée). Chaque protocole s’occupe de dissocier les informations de
bourrage des informations utiles.
2. Fonctionnement
Une liaison PPP se déroule en trois étapes :
2.1 Etape 1 : établissement de la liaison

Pour communiquer sur un lien point à point, les extrémités du lien PPP doivent, pour
commencer, envoyé des paquets LCP (Link Control Protocol) pour configurer, tester et
fermer la liaison de donnée. Un paquet LCP contient des informations, un champ d’option de
configuration pour permettre aux équipements de traiter l’utilisation d’option (comme l’unité
maximale de réception (URM) par exemple), la compression de champs PPP et le protocole
d’authentification de liaison.
2.2 Etape 2 : authentification (optionnel)

Une fois que la liaison et que le protocole d’authentification ont été établies, on peut
authentifier le routeur correspondant. Il y a deux protocoles d’authentification supportée par
PPP :
CHAP (Challenge Handshake Authentification Protocol). Il est à base de challenge ce qui
rend l’obtention du mot de passe par un espion difficile en « écoutant » simplement la
« conversation »).
PAP (Password Authentification Protocol). Il est simple à implémenter. Il a un grand défaut :
le mot de passe circule en clair.
2.3 Etape 3 : configuration des NP par les NCP

Par la suite PPP doit envoyer des paquets NCP (Network Control Protocol) qui permettent de
choisir et de configurer un ou plusieurs protocoles de la couche réseau (NP) disponible(s) (IP
par exemple).
Une fois que tous les protocoles ont été choisis et configurés, on peut commencer à envoyer
les datagrammes de chaque protocole.
La connexion sera ouverte et configuré jusqu'à ce que des paquets LCP ou NCP viennent
fermer la liaison. Un événement extérieur peut interrompre la communication.
Résumé des trois étapes :

Ramqaj Visar
Figure 3 : Les trois étapes d’une connexion PPP
3. Diagramme d’état
Lors d’une tentative de liaison point à point PPP, Il y a plusieurs étapes à passer avant
d’envoyer les données.
Voici le schéma des différentes étapes ci-dessous :
Succès/
Up Ouvrir Aucun
Mort Etablir Identifier
Echec Echec
Fermer
Terminer Réseau
Down
Figure 4 : Diagramme d’état du protocole PPP

Ramqaj Visar
3.1 Phase de liaison morte

C’est un état dans lequel une communication débute et se termine. Cet état correspond à un
moment où la liaison n’est pas prête à recevoir des données. Lors d’un événement extérieur,
elle indiquera que le niveau physique est en état pour lancer une connexion, ce qui va faire
passer la liaison de PPP dans une phase d’établissement de connexion (« Up »).
3.2 Phase d’établissement de liaison

On utilise ici, le protocole de liaison LCP pour établir une connexion grâce à l’échange de
paquets de configuration. Lorsque les paquets d’acquittement (Configuration - Acquittée) on
été reçus des deux côtés l’échange est terminé et l’automate LCP entre dans un état
« Ouvert ».
3.3 Phase d’authentification

Par défaut une authentification n’est pas obligatoire mais si lors des négociations du LCP, une
demande d’authentification particulière (PAP, CHAP, EAP) du correspondant est exigée alors
cette authentification devra être faite le plus tôt possible après la fin de la phase
d’établissement de liaison. Si cette phase d’authentification échoue, la liaison est directement
coupée (« Down »). La phase suivante ne doit pas être possible tant que l’authentification n’a
pas aboutit avec succès.
3.4 Phase de négociation réseau

Une fois que la phase précédente est terminée, chaque protocole réseau (IP, IPx, AppleTalk,
…) doit être configuré séparément via les protocoles NCP (Network Control Protocol).
Chaque NCP doit pouvoir être à l’état « Ouvert » ou « Fermé » à tout moment. Dès qu’un
NCP est dans l’état « Ouvert », la liaison PPP peu alors transmettre les données via le
protocole réseau (NP) associé, et ceci jusqu’à la fermeture de son NCP (NCP à l’état
« Fermé »).
3.5 Phase de fermeture de liaison

La fermeture d’une liaison PPP peut survenir à tout moment à cause de différents facteurs :
Perte de porteuse
Echec d’une authentification
Détection de la qualité de liaison insuffisante
Chute d’une temporisation d’attente
Intervention humaine
C’est grâce à l’utilisation du protocole LCP qui échange des paquets de « Clôture » pour
fermer la liaison. Au cours de la fermeture, le protocole PPP va tout d’abord informer les
couches réseaux afin que celles-ci puissent s’organiser en conséquent.
Les différents NCP actifs ne sont pas obligés d’envoyer leurs paquets de clôture car la
fermeture de liaison LCP suffit amplement. Mais la rupture d’une liaison par NCP n’est pas
une raison suffisante pour interrompre la liaison PPP, même si c’est le dernier NCP actif sur
la liaison.
Sur le schéma ci-dessous, on peut voir le place des différents composants suivant les couches
temporels et leur répartition temporelle.

Ramqaj Visar
Figure 5 : Les différentes étapes d’une connexion PPP au cours du temps

Ramqaj Visar
4. Tramage de données PPP avec des trames

comme-HDLC (rfc 1662 – « HDLC-like
frames »)
Un paquet PPP ne peut pas être envoyé tel quel sur une liaison physique. Un tramage est
nécessaire pour détecter le début et la fin de la trame. De plus lorsque le tramage se fait avec
HDLC, un contrôle d’erreur est effectué. La rfc 1662 définit un tramage basé sur le tramage
HDLC.
4.1 Format des trames
Drapeau Adresse Controle Protocole FCS Drapeau

Information Bourrage
0x7E 0xFF 0x03 8 / 16 bits 16 / 32 bits 0x7E
Figure 6 : Format d’une trame PPP basée sur HDLC
4.1.1 Les champs Drapeau

Ils délimitent le début et la fin de la trame PPP. Ils ont une longueur de 8 bits et prennent la
valeur 0x7E (01111110 binaire). Dans le cas où deux trames se succèdent directement, au lieu
de mettre le Drapeau de fin de la première trame suivi du Drapeau de début de la deuxième
trame, on mettra UN SEUL drapeau entre les deux trames :
… 1ère trame FCS (trame 1) Drapeau Adresse (trame 2) 2ème trame …

Figure 7 : Suite directe de deux trames
4.1.2 Le champ Adresse

La seule valeur définie pour ce champ est 0xFF (11111111 binaire) (= adresse toutes stations)
4.1.3 Le champ Contrôle

La valeur usuelle pour ce champ est 0x03 (00000011 binaire). Dans le protocole HDLC, cette
valeur correspond à une trame non numérotée (U-Frame). En effet, PPP ne se préoccupe pas
de l’ordre d’arrivée des trames. Toutefois, il est possible, quoique plus rare, d’utiliser un
mode numéroté.
4.1.4 Le champ FCS

Par défaut sa longueur est de 16 bits, il peut être modifié à 32 bits grâce au protocole LCP. Il
est calculé sur les champs adresse, contrôle, protocole, information et bourrage en n’incluant
ni les bits d’arrêt et de début, ni les bits et octets insérés ou modifiés pour la transparence.
4.2 Le problème de la transparence

Lors de la conception de PPP, une des condition à respecter était la transparence : il ne fallait
pas que les protocoles à encapsuler dussent respecter certaines contraintes, cela veut
notamment dire qu’un protocole désirant se faire encapsuler par PPP peut utiliser n’importe
quelle séquence de bits. Or cela pose un problème : Si le protocole à encapsuler utilise une
Ramqaj Visar
séquence de bits correspondant au Drapeau (ie. 0x7E = 01111110 en binaire), la séquence
serait prise pour la fin de la trame.
4.2.1 Tramage à octet de bourrage (pour les liens asynchrones 8 bits et synchrones
octets)
On utilise l’octet d’échappement 0x7d (= 01111101 binaire). Chaque octet ayant la même
valeur que le drapeau ou que l’octet d’échappement est échappé. Tous les octets présents dans
la table des caractères de contrôle asynchrone d’envoi (ACCM « Async-Control-Character-
Map ») sont également échappés (ACCM peut contenir typiquement des caractères tels que
XON, XOFF, …)
L’échappement se passe de la manière suivante :
Faire précéder le caractère à échapper par l’octet d’échappement
Transformer le caractère à échapper par un ou exclusif de lui-même avec 0x20 (00100000
binaire)
Exemples :
0x7e → 0x7d, 0x5e
0x7d → 0x7d, 0x5d
0x03 → 0x7d, 0x23
4.2.2 Tramage par bit de bourrage (pour les liens synchrones orientés bit)
Avant l’envoi d’une trame, mais après que le FCS soit calculé, on considère tous les champs
entre le drapeau de début et celui de fin de la trame. Chaque fois que 5 bits contigus sont à
« 1 », on insère un « 0 » après le groupe de 5 bits à « 1 ».
A la réception, on effectue l’opération inverse : on considère tous les champs entre le drapeau
de début et celui de fin de trame, et chaque fois que 5 bits contigus sont à « 1 », on supprime
le « 0 » qui suit.
Exemple :
à envoyer : …1101 1111 1111 1111 1011 …
envoyé : …1101 1111 0111 1101 1110 11…

Ramqaj Visar
5. Les protocoles NCP

Il s’agit ici d’un ensemble de protocole qui permettent de configurer les paramètres
spécifiques à un protocole de la couche réseau. Pour la plupart des types de protocole réseau
disponibles, il y a un NCP correspondant.
Par exemple, le NCP du protocole IP est le IP Control Protocol (IPCP). IPCP permet entre
autres la configuration de l'adresse IP utilisée, des serveurs DNS primaire(s) et secondaire(s).
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é).
Voici un schéma qui donne les détails du paquet NCP :
Quelques explications du schéma :

• Code - Le champ Code comporte un octet, et identifie le type de paquet NCP.
Code Type de paquet Signification

1 Configure - Request Départ de la connexion, définit et négocie la configuration
2 Configure - ACK Accusé de la réception d'un Configure-Request
3 Configure - NAK Réponse négative à la réception d'un Configure-Request
4 Configure - Reject Options de configurations non reconnaissables
5 Terminate - Request Fermeture de la connexion
6 Terminate - ACK Accusé de la réception d'un Terminate-Request
7 Code - Reject Code reçu inconnu
8 Protocol - Reject Réception avec une valeur de protocole inconnu
9 Echo - Request Loopback pour la détermination de la qualité du lien
10 Echo - Reply Réponse au Echo-Request
11 Discard - Request Ignore la requête reçue

Ramqaj Visar
• 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.

Ramqaj Visar
6. Le protocole LCP (rfc 1661)

Il est utilisé pour gérer la liaison de données : établissement, configuration, test et fermeture
de la liaison de données.
Comme les autres protocoles utilisés dans PPP, le LCP encapsule ses données dans une trame
PPP. Un seul paquet peut être encapsulé dans une trame PPP. Le champ Protocole contient
l’identifiant du LCP qui est 0x0c21.
6.1 Format des paquets LCP
Code Identifier Longueur

Données
8 bits 8 bits 16 bits
Figure 3 : format d’un paquet LCP
6.1.1 Le champ Code

Il indique le type de paquet LCP. Les paquets sont répartis en trois classes de paquets :
1. Les paquets de Configuration de Liaison utilisés pour établir et configurer une
communication (codes 1 à 4)
2. Les paquets de Fermeture de Liaison utilisés pour couper une communication (codes 5
et 6).
3. Les paquets de Maintenance de Liaison (ou lien) utilisés pour gérer et déterminer une
liaison (codes 7 à 13)
Le type de paquets peut être un des suivants :
Code type de paquet

0 Vendor Specific (rfc 2153)
1 Configure-Request
2 Configure-Ack
3 Configure-Nak
4 Configure-Reject
5 Terminate-Request
6 Terminate-Ack
7 Code-Reject
8 Protocol-Reject
9 Echo-Request
10 Echo-Reply
11 Discard-Request
12 Identification (rfc 1570)
13 Time-Remaining (rfc 1570)

Ramqaj Visar
6.1.2 Le champ identifier

D’une longueur d’un octet, il permet d’associer requêtes et réponses.
6.1.3 Le champ Longueur

D’une longueur de deux octets, il donne la longueur du paquet LCP, y compris les champs
Code, Identifier, Longueur et Données.
6.1.4 Le champ données

Sa signification dépend de la valeur du champ Code.
6.2 Types de paquets LCP

6.2.1 Code 0 : Vendor Specific (rfc 2153)
Ce type de paquet est disponible pour des implémentations propriétaires.
6.2.2 Code 1 : Configure-Request (demande de config. d’options)

Ce type de paquet doit être envoyé lorsqu’on désire initialiser une communication.
Sur réception de ce type de paquet, une réponse appropriée doit être émise.
Le champ Identifier
Il doit changer lorsque le contenu des options change et qu’une réponse valide a été reçue
pour la requête précédente. S’il s’agit d’une retransmission, il peut rester inchangé.
Le champ Données
Il contient une liste d’options à configurer. Seules les options dont on désire changer la valeur
par défaut doivent apparaître.
6.2.3 Code 2 : Configure-Ack (Acceptation de la modification d’options)

Ce type de paquet est envoyé après réception d’un Configure-Request, et lorsque toutes les
options du Configure-Request sont reconnues et acceptées.
Le champ Identifier
Il contient une copie de l’identifier du paquet Configure-Request reçu.
Le champ Données
Il contient une copie du champ Données du paquet Configure-Request reçu.

Ramqaj Visar
6.2.4 Code 3 : Configure-Nak (Non-acceptation de la modification d’options)

Ce type de paquet est envoyé lorsque toutes les options sont reconnues, mais que certaines
valeurs ne sont pas acceptées.
Le rejet d’options sans champ de valeur (options booléennes) s’effectue à l’aide de paquets
Configure-Reject.
Un Configure-Nak indique à son récepteur les valeurs acceptées et fait office de demande
d’un nouveau paquet Configure-Request
Le champ Identifier
Il contient une copie de l’identifier du paquet Configure-Request auquel ce paquet répond.
Le champ Données
Il contient les options non-acceptées de la requête correspondante reçue. Les options refusées
doivent apparaître dans le même ordre qu’elles ont été reçues.
6.2.5 Code 4 : Configure-Reject (Rejet définitif de certaines options)

Ce type de paquet est envoyé lorsque certaines options reçues dans une requête ne sont pas
reconnues ou pas négociables. Le Configure-Reject indique que ces options ne devront plus
figurer dans aucun paquet ultérieur.
Le champ Identifier
Il contient une copie de l’identifier du paquet Configure-Request auquel ce paquet répond.
Le champ Données
Il contient les options non reconnues ou non négociables de la requête correspondante reçue.
Ces options doivent apparaître dans le même ordre qu’elles ont été reçues.
6.2.6 Code 5 et 6 : Terminate-Request et Terminate-ack (Fermeture de la connexion)

Lorsqu’on souhaite fermer la connexion, on envoie en continu un paquet Terminate-Request
jusqu’à la réception d’un paquet Terminate-ack, ou jusqu’à ce que la couche inférieure ait
signalisé sa désactivation, ou encore jusqu'à ce que le nombre de requêtes soit suffisant pour
que le distant puisse être raisonnablement considéré comme déconnecté.
Sur réception d'un Terminate-Request, un paquet Terminate-ack DOIT être renvoyé.
La réception d'un paquet Terminate-ack sans sollicitation indique que le distant est dans un
des états Fermé ou Arrêté, ou réclame une renégociation de la liaison.
Le champ Identifier
Lors de l'émission, la valeur d'identification est modifiée chaque fois que le contenu du champ
de Données change, et dès qu'une réponse valide a été reçue pour une requête antérieure. Lors
de la retransmission d'une même requête, la valeur d'identification reste inchangée.
Lorsqu’un paquet Terminate-Request est reçu, son champ Identifier est recopié dans le champ
Identifier du paquet Terminate-ack à émettre en réponse.
Le champ Données
Il contient des données non interprétées à l’usage de l’expéditeur.
6.2.7 Code 7 : Code-Reject

Ramqaj Visar
Ce type de paquet est envoyé lors de la réception d’un paquet dont le code est inconnu.
Le champ Identifier
Il change à chaque émission d’un nouveau rejet.
Le champ données
Il contient une copie du paquet LCP refusé. Si cette copie entraîne un dépassement de l’unité
de réception maximale (URM), la copie est tronquée.
6.2.8 Code 8 : Protocol-Reject

Ce type de paquet est envoyé lorsque le protocole encapsulé dans PPP n’est pas reconnu.
Le champ Identifier
Il change à chaque émission d’un nouveau rejet.
Le champ données
Il est divisé en deux parties : Protocole rejeté (2 octets) qui contient la copie du champ du
protocole PPP du paquet refusé, et Information rejetée qui contient la copie du paquet refusé
(sans en-tête de la couche liaison de données (p.ex Drapeaus), ni de FCS). L’information
rejetée doit être tronquée si nécessaire pour se conformer à l’URM maximale du distant.
6.2.9 Code 9 et 10 : Echo-Request et Echo-Reply

Lors de la réception d’un Echo-Request, le destinataire répond par un Echo-Reply. Ces
paquets permettent d’implémenter des fonctions de test, de mesurer la qualité de la ligne, de
mesurer les performances, et plus encore.
Le champ Identifier
En transmission, la valeur d'identification est changée dès que le contenu du champ de
Données_I est modifié, ou qu'une réponse valide a été reçue pour une requête donnée. Lors
des retransmissions, la valeur d'identification peut rester inchangée.
En réception, l'identificateur d'un Echo-Request sera copié dans le Echo-Reply émis en retour.
Le champ Données
Il est divisé en deux parties : Le Nombre-Magique (4 octets) qui permet de détecter des
liaisons en condition de rebouclage (l’expéditeur reçoit ses propres paquets) et un champ
Données_I qui contient des données non interprétées. La longueur de ce champ peut être
calculée à partir de la valeur du champ longueur.
Le nombre magique vaut 0 tant que l’option de configuration relative au nombre magique n’a
pas été négociée avec succès.
6.2.10 Code 11 : Discard-Request

(Requête-Elimination)
Ce paquet permet d’effectuer des tests de la couche Liaison de données dans le sens local vers
distant. Il permet d’effectuer du débuggage, des tests de performances et un certain nombre
d’autres fonctionnalités.
Lors de la réception, un tel paquet est ignoré.
Le champ Identifier
Il est différent pour chaque paquet Discard-Request envoyé.

Ramqaj Visar
Le champ Données
Données_I qui contient des données non interprétées. La longueur de ce champ peut être
calculée à partir de la valeur du champ longueur.
6.2.11 Code 12 : Identification (rfc 1570)

Ce paquet permet à une implantation de s’identifier à un pairs. Aucune réponse n’est attendue
en retour de ce paquet.
Le champ Identifier
Il change pour chaque identification émise.
Le champ Donnée
message qui contient des données dont la signification dépend de l’implantation. La longueur
de ce champ peut être calculée à partir de la valeur du champ longueur.
6.2.12 Code 13 : Time-Remaining (rfc 1570)

Ce paquet permet d’informer le pair du temps restant pour la session en cours. Normalement,
seul un des deux communiquant envoie ce paquet.
Le champ Identifier
Il change pour chaque paquet Time-Remaining émis
Le champ Donnée
Il est divisé en trois parties : Le Nombre-Magique (4 octets) qui permet de détecter des
liaisons en condition de rebouclage (l’expéditeur reçoit ses propres paquets), un champ
Secondes (4 octets) indique le nombre de secondes restantes pour la session en cours, et un
champ message qui contient des données dont la signification dépend de l’implantation. La
longueur de ce champ peut être calculée à partir de la valeur du champ longueur.
Le champ Secondes contient une valeur non signée de 32 bits. La valeur 0xffffffff signifie
qu’aucun délai n’est fixé (délai infini).
6.3 Format des options des paquets LCP

Les options permettent de modifier les valeurs par défaut des paramètres de la connexion
PPP. La valeur par défaut est utilisée pour une option tant que celle-ci n’a pas été configurée.
Lors d’une requête Configuration-Request (code 1), si une option n’est pas spécifiée, sa
valeur par défaut est utilisée.

Ramqaj Visar
Normalement, les options de configuration concernent les caractéristiques attendues en
réception par l’émetteur de la requête.
Des valeurs par défaut existent pour chaque option, ce qui permet d’utiliser une
communication PPP sans paramétrer les options.
6.3.1 Format général des options
Type Longueur
Données
8 bits 8 bits
Figure 4 : format général des options LCP
6.3.2 Champ Type

Le type est l’un des suivants2 :
Code Type
0 Vendor Specific (RFC 2153)
1 MRU (Maximum Receive Unit ; URM en français : unité de réception maximale)
2 Async Control Character Map
3 Authentification Protocol
4 Quality Protocol
5 Magic Number
6 obsolète (Quality Protocol)
7 Protocol Field Compression
8 Address and Control Field Compression
9 FCS Alternatives (RFC 1570)
10 Self Describing Pad (RFC 1570)
11 Numbered Mode (RFC 1663)
12 obsolète (Multi Link Procedure)
13 Callback (RFC 1570)
14 obsolète (Connect Time)
15 obsolète (Compound Frames)
16 obsolète (Nominal Data Encapsulation)
17 Multilink MRRU (RFC 1717)
18 Multilink Short Sequence Number Header (RFC 1717)
19 Multilink Endpoint Discriminator (RFC 1717)
20 Propriétaire
21 DCE Identifier
22 Multi Link Plus Procedure
23 Link Discriminator for BACP
24 LCP Authentification Option
25 Consistent Overhead Byte Stuffing (COBS)
26 Prefix elision
27 Multilink header format
28 Internationalization (RFC2484)
29 Simple Data on SONET/SDH
2
D’autres options sont susceptibles d’être ajoutées. Consulter http://www.iana.org/assignments/ppp-numbers

Ramqaj Visar
6.3.3 Champ longueur
Il spécifie la longueur de l’option avec en prenant en compte les champs type, longueur et
données.
6.4 Les options de base des paquets LCP

6.4.1 Code 1 : MRU Maximum Receive Unit
Permet d’informer le distant de la taille maximale que l’implémentation est capable de gérer
en réception. Le distant peut envoyer des paquets d’une taille plus petite ou égale au MRU,
mais jamais plus grands.
Longueur
4 octets
Données
Le champ MRU codé sur deux octets. Il indique le nombre maximal d’octets que peuvent
contenir les champs information et bourrage cumulés. Le champ protocole et autres champs
de tramage ainsi que les bits ajoutés par le tramage ne sont pas inclus dans cette taille de
MRU.
6.4.2 Code 3 : Authentification Protocol

Permet l’utilisation d’un protocole d’authentification afin d’autoriser le transit d’autres
protocoles NCP. Cette option ne peut être présente qu’une seule fois par requête. Il se peut
qu’un protocole ne supporte pas certains protocoles d’authentifications, c’est pourquoi, tant
que l’option est refusée, plusieurs requête demandant d’utiliser différents protocoles peuvent
être envoyées.
Lorsque le protocole est accepté par le récepteur de la demande d’authentification,
l’expéditeur attend l’authentification en activant le protocole correspondant.
Longueur
Plus grande ou égale à 4 octets
Données
Le champ de données est séparé en deux. La première partie contient le numéro du protocole
d’authentification sur 16 bits. Par exemple, C023 => PAP (protocole d’identification par mot
de passe) ; C223 => CHAP (protocole par échange de certificats). Les autres identifiants sont
listés à http://www.iana.org/assignments/ppp-numbers.
L’autre partie du champ de données contient 0 ou plus octets dont la signification dépend du
protocole utilisé.
6.4.3 Code 4 : Quality Protocol

Permet d’utiliser un protocole de contrôle de qualité de la liaison (déterminer quand et dans
quelle proportion la liaison perd des données). Par défaut le contrôle de qualité est désactivé.
Lorsqu’une Configuration-Request avec l’option Quality Protocol est acceptée, celui qui l’a
accepté démarre un échange avec le protocole convenu.
Longueur
Plus grande ou égale à 4 octets.

Ramqaj Visar
Données
Le champ de données est séparé en deux. La première partie contient le numéro du protocole
de qualité sur 16 bits. Par exemple, C025 => Link Quality Report. Les autres identifiants sont
listés à http://www.iana.org/assignments/ppp-numbers.
L’autre partie du champ de données contient 0 ou plus octets dont la signification dépend du
protocole utilisé.
6.4.4 Code 5 : Nombres magiques

Cette option permet de détecter des rebouclements ou autres problèmes sur la couche Liaison
de données. Si elle n’est pas négociée, les nombres magiques ne sont pas utilisés et un 0 est
placé là où le nombre magique devrait apparaître.
Une machine choisi son propre nombre magique d’une façon aléatoire afin qu’il soit unique
pour n’importe quels deux machines dialoguant avec PPP.
Le mécanisme est le suivant :
Lorsqu’une machine reçoit une Configuration-Request qui précise le nombre magique, ce
dernier est comparé avec la dernière requête émise. Si les deux nombres sont différents, la
liaison n’est pas bouclée. Par contre, s’ils sont identiques, la liaison est probablement bouclée
et la requête reçue serait alors la dernière requête envoyée. Afin de vérifier si la ligne est
vraiment bouclée, un paquet Configuration-Nak (configuration non acquittée) avec un
nouveau nombre magique est envoyé. Si lors de la réception du prochain paquet, le nombre
magique est de nouveau le même, on renvoie une nouvelle Configuration-Nak avec un
nouveau nombre magique choisi au hasard. La répétition de cette étape plusieurs fois qui
mène chaque fois au même nombre magique émis que reçu indique qu’il y a bien une boucle.
Si le nombre magique n’est ni égal à son propre nombre magique (rebouclement) ni au
nombre magique du distant (négocié auparavant), ni égal à 0, il y a une erreur dans la
configuration de la liaison.
Longueur
6 octets
Données
Le nombre magique sur 32 bits, supposé être différent de celui de vis-à-vis. 0 est une valeur
non valable.
6.4.5 Code 7 : Protocol Field Compression

Cette option permet la compression du champ protocole des paquets PPP. Elle permet
d’informer le récepteur du paquet que l’expéditeur accepte un champ de protocole compressé.
Les identifieurs (codes) des protocoles sont répartis de telle manière qu’il est possible de
ramener la longueur du champ protocole à un octet pour tous les protocoles dont l’identifiant
est inférieur à 256. Des identifiants de protocoles compressés ET non compressés peuvent être
reçus par une implémentation qui accepte le champ protocole compressé. Il faut donc un
moyen de discriminer si le champ protocole est compressé ou non. Le mécanisme (qui est
celui de l’ISO 3309) est le suivant :
Les numéros (identifieurs) de protocoles se terminent tous par un bit à 1 et l’octet de poids
fort se termine par un bit à 0. Au niveau du récepteur, la discrimination se fait comme suit : si
le premier octet du champ protocole se termine par un 1, c’est que le champ protocole est

Ramqaj Visar
compressé, et qu’il n’y a donc pas de deuxième octet. Si au contraire le premier octet se
termine par 0, c’est que le champ protocole n’est pas compressé et qu’il y a un deuxième
octet. Exemple :
Utilisation du protocole IP (0021hex), le destinataire accepte la compression du

champ protocole.
Sans compression : 0021 => 0000 0000 0010 0001
Le récepteur sait qu’il y a encore Le récepteur sait qu’il vient de lire

un octet grâce à ce 0. le dernier octet grâce à ce 1.
Avec compression : 21 => 0010 0001
Le récepteur sait qu’il vient de lire

le dernier octet grâce à ce 1.
Le champ protocole n’est jamais compressé lors de l’envoi de paquets LCP.

Lorsqu’il y a compression du champ protocole, le FCS de la couche liaison de données est
calculé sur la trame compressée et non sur la trame originale.
Longueur
2 octets
Données
Le champs de données est toujours vide (0 octets).
6.4.6 Code 8 : Address and Control Field Compression (ACFC)

Cette option permet la compression (suppression3) des champs d’adresse et de contrôle de la
couche de données. Elle permet d’informer le récepteur du paquet que l’expéditeur du paquet
accepte la compression des champs address et control. Cette compression est possible dans la
mesure où les champs control et address ont souvent des valeurs non utilisées.
Les champs address et control ne sont jamais compressés lors de l’envoi de paquets LCP.
Lorsqu’il y a compression des champs address et control, le FCS de la couche liaison de
données est calculé sur la trame compressée et non sur la trame originale.
Longueur
2 octets
Données
Le champs de données est toujours vide (0 octets).
3
RFC 1661 n’explicite pas qu’il s’agit d’une suppression, mais http://www.freesoft.org/CIE/RFC/1812/40.htm
oui.

Ramqaj Visar
7. Décodage d’une trame PPP

7.1 La trame PPP
7e ff 7d 23 c0 21 7d 21 7d 21 7d 20 7d 38 7d 22
7d 26 7d 20 7d 20 7d 20 7d 20 7d 23 7d 24 c2 27
7d 25 7d 26 74 30 7d 3d fb 7d 27 7d 22 7d 28 7d
22 fe 80 7e
7.2 Détrammage
| dé-échappé | reçu | signification
------------+-------------+-------------------------+--------------
start flag: | 7e | 7e |
address: | ff | ff |
contrôle: | 03 | 7d 23 |
Protocole: | c0 21 | c0 21 | LCP
Information:| 01 01 00 18 | 7d 21 7d 21 7d 20 7d 38 |
| 02 06 00 00 | 7d 22 7d 26 7d 20 7d 20 |
| 00 00 03 04 | 7d 20 7d 20 7d 23 7d 24 |
| c2 27 05 06 | c2 27 7d 25 7d 26 |
| 74 30 1d fb | 74 30 7d 3d fb |
| 07 02 08 02 | 7d 27 7d 22 7d 28 7d 22 |
| fe 80 | fe 80 |
end flag: | 7e | 7e |
------------+-------------+-------------------------+---------------
7.3 Décodage LCP

code: 01 Requête-configuration
Identific.: 01
Longueur: 00 18
Données: 02 06 00 00
00 00 03 04
c2 27 05 06
74 30 1d fb
07 02 08 02
bourrage PPP:fe 80
7.4 Décodage des options

Type: 02 ACCM
Longueur: 06
Données 00 00 00 00
Type: 03 protocole-authentification
Longueur: 04
protocole: c2 27 Extensible Authentication Protocol [RFC2284]
Type: 05 nombres-magiques
Longueur: 06
74 30 1d fb
Type: 07 compression-protocoles
Longueur: 02
Type: 08 compression-adresses-et-contrôles (ACFC)
Longueur: 02

Ramqaj Visar
8. Conclusion
Le protocole PPP offre la possibilité, grâce au principe de l'encapsulation, de transporter
simultanément des données de plusieurs protocoles de la couche réseau. Une trame standard
transporte toutes ces données. Ce protocole permet également de prendre en compte de
nouveaux protocoles de la couche réseau au fur et à mesure de leur apparition : il suffit pour
cela de définir un protocole de contrôle associé et de leur attribuer un numéro.
Le protocole LCP est très important car il permet d’assurer une bonne portabilité de PPP. Il
permet en effet, par l'intermédiaire des multiples options qu'il gère, une adaptation à
l'environnement et aux exigences de la ligne. De plus, c'est lui qui prend en charge l'ouverture
et de la fermeture de la liaison de données, une éventuelle authentification, la détection des
erreurs et donc la qualité de la liaison, mais aussi que la détection d’éventuels bouclages.
Ce protocole c’est imposé comme standard d’échange sur le réseau. Pour assurer plus de
sécurité des entreprise on mis au point de nouvelles technologies basées sur le protocole PPP
mais qui assure plus de confidentialité quant au contenu de la trame.
Exemple : le protocole PPTP (protocole point à point en mode tunnel).
D’autres protocoles basées sur le PPP on vue le jour ces dernières années. Ces nouveaux
protocoles amène de nouvelles spécificités. En voici les plus important :
• PPPoE : PPP over Ethernet
• L2TP : Layer 2 Tunneling Protocol

Ramqaj Visar
9. Bibliographie
9.1 Liens Internet
http://abcdrfc.free.fr/rfc-vf/pdf/rfc1661.pdf
Auteur : W. Simpson
Année : Juillet 1994
http://kia.etel.ru/lib/Networking/kurose/ethernet/ppp.htm, rfc1662
Auteurs : Keith W. Ross and Jim Kurose
Année : 1996-1999
http://www.labouret.net/ppp/
Auteurs : Ghislaine Labouret, Jean-Christophe Lator
Année : 1996
http://www.commentcamarche.net/internet/ppp.php3
Auteur : Jean-François Pillou
Année : 2005
http://www.labo-cisco.com/ArticleComp.asp?ARID=38
Auteur : Sivan Deray
Année : 2000
http://ylescop.free.fr/mrim/protocoles/rfc-fr/rfc1663.htm
Auteur : D. Rand
Année : 1994
http://www.freesoft.org/CIE/RFC/1812/40.htm
Auteur : F. Baker, Editor Cisco Systems
Année : 1995
Source pour les codes :
http://www.iana.org/assignments/ppp-numbers
Auteur : The Internet Corporation for Assigned Names and Numbers
Année : 2001

Ramqaj Visar

PPP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PPP

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de

Auteur : Jann Daniel, Ramqaj Visar

Le Locle, le 15 avril 2005

Table des matières

Jann Daniel Page 2 sur 26 Le Locle, le 15 avril 2005

Jann Daniel Page 3 sur 26 Le Locle, le 15 avril 2005

Jann Daniel Page 4 sur 26 Le Locle, le 15 avril 2005

Figure 1 : établissement d’une connexion PPP

Jann Daniel Page 5 sur 26 Le Locle, le 15 avril 2005

Protocole (8 ou 16 bits) Information Bourrage

Figure 2 : format d’un paquet PPP

1.1 Le champ protocole

Jann Daniel Page 6 sur 26 Le Locle, le 15 avril 2005

1.2 Le champ Information

1.3 Le champ bourrage

2.1 Etape 1 : établissement de la liaison

2.2 Etape 2 : authentification (optionnel)

2.3 Etape 3 : configuration des NP par les NCP

Jann Daniel Page 7 sur 26 Le Locle, le 15 avril 2005

Figure 3 : Les trois étapes d’une connexion PPP

Figure 4 : Diagramme d’état du protocole PPP

Jann Daniel Page 8 sur 26 Le Locle, le 15 avril 2005

3.1 Phase de liaison morte

3.2 Phase d’établissement de liaison

3.3 Phase d’authentification

3.4 Phase de négociation réseau

3.5 Phase de fermeture de liaison

Jann Daniel Page 9 sur 26 Le Locle, le 15 avril 2005

Figure 5 : Les différentes étapes d’une connexion PPP au cours du temps

Jann Daniel Page 10 sur 26 Le Locle, le 15 avril 2005

4. Tramage de données PPP avec des trames

4.1 Format des trames

Drapeau Adresse Controle Protocole FCS Drapeau

4.1.1 Les champs Drapeau

… 1ère trame FCS (trame 1) Drapeau Adresse (trame 2) 2ème trame …

4.1.2 Le champ Adresse

4.1.3 Le champ Contrôle

4.1.4 Le champ FCS

4.2 Le problème de la transparence

Jann Daniel Page 12 sur 26 Le Locle, le 15 avril 2005

5. Les protocoles NCP

Quelques explications du schéma :

Code Type de paquet Signification

Jann Daniel Page 13 sur 26 Le Locle, le 15 avril 2005

Jann Daniel Page 14 sur 26 Le Locle, le 15 avril 2005

6. Le protocole LCP (rfc 1661)

6.1 Format des paquets LCP

Code Identifier Longueur

6.1.1 Le champ Code

Code type de paquet

Jann Daniel Page 15 sur 26 Le Locle, le 15 avril 2005

6.1.2 Le champ identifier

6.1.3 Le champ Longueur

6.1.4 Le champ données

6.2 Types de paquets LCP

6.2.2 Code 1 : Configure-Request (demande de config. d’options)

6.2.3 Code 2 : Configure-Ack (Acceptation de la modification d’options)

Jann Daniel Page 16 sur 26 Le Locle, le 15 avril 2005

6.2.4 Code 3 : Configure-Nak (Non-acceptation de la modification d’options)

6.2.5 Code 4 : Configure-Reject (Rejet définitif de certaines options)

6.2.6 Code 5 et 6 : Terminate-Request et Terminate-ack (Fermeture de la connexion)

6.2.7 Code 7 : Code-Reject

Jann Daniel Page 17 sur 26 Le Locle, le 15 avril 2005

6.2.8 Code 8 : Protocol-Reject