Une méthode pour la transmission du PPP sur ethernet

(A Method for Transmitting PPP Over ethernet (PPPoE) )

Statut de ce mémo

Ce mémo procure une information à la communauté internet. il ne spécifie en aucun cas un standard internet. La distribution de ce mémo est libre.

Copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

Notes de traduction

Le texte original est traduit aussi fidèlement que possible, Les acronymes issus de mots anglais sont conservés tel quels mais généralement explicités à leur première occurrence. Des notes de traduction (N.D.T.) peuvent préciser des concepts qui se décrivent en anglais avec un seul mot ainsi que des caractéristiques ou exceptions françaises.

Résumé

Le protocole PPP [1] permet de transporter des datagrammes multi-protocoles à travers un lien point à point.

Ce document décrit la construction des sessions PPP et l'encapsulation des paquets PPP sur ethernet.

Application 

Cette spécification essaie de présenter les caractéristiques définies pour le PPP, comme le Protocole de Contrôle des Liens (LCP), le Protocole de Contrôle de la couche Réseau (NCP), d'authentification, et plus. Ces protocoles requièrent une relation point à point entre les deux extrémités et ne sont pas faits pour des liaisons multipoints telles qu'ethernet et d'autres environnements multi-accès.

Cette spécification peut être employée par des hôtes multiples sur un réseau ethernet partagé afin d'ouvrir des sessions PPP sur des directions multiples via un ou plusieurs modems pontés. PPPoE est utilisé sur des technologies d'accès distants large bande présentant une topologie ethernet pontée. PPPoE est utilisé lorsque les fournisseurs d'accès souhaitent maintenir l'abstraction de session associé à PPP.

Ce document décrit l'encapsulation de PPP sur ethernet qui est déployée par RedBack Network, RouterWare, UUNet et d'autres.

Table des matières

1. Introduction
2. Conventions
3. Vue d'ensemble du protocole
4. Charges utiles
5. L'étape de découverte
5.1 Le paquet de découverte « Initialisation » (PADI)
5.2 Le paquet de découverte « Offre » (PADO)
5.3 Le paquet de découverte « Requête » (PADR)
5.4 Le paquet de découverte « Confirmation de session » (PADS)
5.5 Le paquet de découverte « Terminaison » (PADT)
6. L'étape de la session PPP
7. Considérations LCP
8. Quelques considérations
9. Considérations de sécurité
10. Remerciements
11. Références
12. Annexe A
13. Annexe B
14. Adresses des auteurs
15. Copyright intégral

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 inclus donc un protocole de découverte.

2. Conventions

Les mots-clefs doit , ne doit pas, requis, devrait, ne devrait pas, recommandé , peut et optionel, lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit dans [2].

3. Vue d'ensemble du protocole

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. Charges utiles

Les formats des paquets suivants sont définis ici. Le contenu de la charge utile sera défini dans les sections « découverte » et « PPP ».

La trame ethernet est définie comme suit :

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5
Adresse de destination (6 octets)
Adresse source (6 octets)
Type ethernet (2octets)
Charge utile
Somme de contrôle

Le champ « Adresse de destination » contient soit l'adresse ethernet fixe du destinataire, soit l'adresse ethernet de diffusion(0xffffffff).(N.D.T. Adresse fixe, unicast en anglais, veut dire que la trame s'adresse à un destinataire unique et identifié; adresse de diffusion (broadcast) veut dire que la trame s'adresse à toutes les adresses du réseau.) Pour les paquets de découverte, la valeur est soit une adresse fixe, soit une adresse de diffusion comme cela est défini dans la partie traitant de l'étape de la découverte. Lors de la session PPP, ce champ doit contenir l'adresse fixe du vis à vis déterminée lors de l'étape de découverte.

Le champ « Adresse source » doit contenir l'adresse MAC du périphérique ethernet.

Le champ « type ethernet » contient soit 0x8863 pour l'étape de la découverte, soit 0x8864 pour la session PPP.

La charge utile , pour PPPoE, se définie comme suit :

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Version				Type				Code								Identificateur de session
Longueur																Charge utile ...												...

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.

Identificateur de session : 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.

5. L'étape de découverte 

L'étape de découverte s'effectue en quatre temps. Quand elle s'achève, chaque vis à vis connait 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 concentrateur 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 :

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Type																Longueur
Valeur ...																												...

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é.

Quelques exemples de paquets de découvertes sont présentés en annexe B.

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

Les hôtes envoient le paquet PADI 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'en-tê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 ».

5.2 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. 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.

5.3 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 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.

5.4 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. 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.

5.5 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 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 peux pas.

6. L'étape de la 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.

7. Considérations LCP

L'option de configuration du numéro magique LCP est recommandée alors que l'option de compression des champs (PFC) n'est pas recommandée. Une implémentation ne doit pas avoir recours à l'une des options suivantes, et doit rejeter une demande pour de telles options :

- 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).

L'option « Unité de réception maximale » (MRU) ne doit pas être négociée à une taille supérieure à 1492. Du fait que la taille maximum de la charge utile ethernet est de 1500 octets, que l'en-tête PPPOE est de 6 octets et que l'identificateur de protocole est de 2 octets, le MTU de PPP ne doit pas dépasser 1492.

Il est recommandé que le concentrateur d'accès envoie occasionnellement des paquets « Echo - Demande » à l'hôte afin de déterminer l'état de la session. Sans cela, si l'hôte termine la session sans envoyer le paquet « Terminaison - Demande », le concentrateur d'accès ne sera pas capable de savoir que la session a disparue.

Quand le protocole de contrôle du lien (LCP) se termine, l'hôte et le concentrateur d'accès doivent arrêter d'utiliser cette session PPPoE. Si l'hôte désire démarrer une autre session PPP il doit retourner à l'étape de découverte PPPoE.

8. Quelques considérations

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 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.

UTF-8 [5] est utilisé dans ce document (N.D.T. Dans le document original en anglais) plutôt que l'ASCII. UTF-8 comprend aussi bien le jeu de caractère ASCII que les jeux de caractères internationaux. Voir [5] pour plus de détails. (N.D.T. Cette version française au format HTML utilise le jeu de caractère iso-8859-1).

9. Considérations de sécurité

A des fins de protection contre les attaques par denie de service (DOS), le concentrateur d'accès peut employer le TAG « Concentrateur d'accès - Cookie ». Le concentrateur d'accès doit être capable de recréer la valeur unique du TAG basée sur l'adresse source. Grâce à cela, le concentrateur d'accès peut s'assurer que l'adresse source du paquet PADI peux réellement être atteinte et il peut donc limiter les sessions concurentes pour cette adresse. L'algorithme à utiliser n'est pas défini et est considéré comme un détail d'implémentation. Un exemple est HMAC [3] dans « Adresse MAC de l'hôte » qui utilise une clé connue seulement du concentrateur d'accès.

Bien que « Concentrateur d'accès - Cookie » soit utile contre des attaques DOS, un concentrateur d'accès peut employer d'autres méthodes pour se protéger.

Un certain nombre de concentrateurs d'accès ne souhaitent pas donner à une entité non authentifiée des informations sur les services qu'ils offrent. Dans ce cas le concentrateur d'accès doit employer une de ces deux règles. Il ne doit jamais refuser une demande basée sur le TAG « Nom du service » et toujours retourner la valeur du TAG qui lui a été envoyé ou bien il ne doit accepter que les demandes avec un TAG « Nom du service » de longueur non nulle (Indiquant n'importe quel service). La première solution est recommandée.

10. Remerciements

Ce document s'est basé sur des idées discutées dans plusieurs forums, y compris le forum ADSL.

Une grande quantité de texte a été pillée dans les RFC 1661, 1662 et 2364.

11. Références

[1] W. Simpson, Editeur, « Le Protocole Point-à-Point (PPP) » (The Point-to-Point Protocol -PPP), STD 51, RFC 1661, Juillet 1994.

[2] S. Bradner, « Mots-clefs à utiliser dans les RFC pour indiquer les niveaux d'exigences » (Key words for use in RFCs to Indicate Requirement Levels), BCP 14, RFC 2119, Mars 1997.

[3] H. Krawczyk, M. Bellare et R. Canetti, « HMAC: Utilisation de clefs dans une table de hachage pour l'Authentification de Message » (HMAC: Keyed-Hashing for Message Authentication), RFC 2104, Février 1998.

[4] J. Reynolds et J. Postel, « Numéros Affectés » (Assigned Numbers), STD 2, RFC 1700, Octobre 1994. Voir aussi : http://www.iana.org/numbers.html

[5] F. Yergeau, « UTF-8, un format dérivé de l'ISO 10646 » (UTF-8, a transformation format of ISO 10646), RFC 2279, Janvier 1998.

12. Annexe A

Types de TAG et valeurs des TAGs

0x0000 Fin de liste
Ce TAG indique qu'il n'y a plus d'autre TAGs dans la liste.La longueur de ce TAG doit toujours être de 0. L'utilisation de ce TAG n'est pas obligatoire mais est conservée pour compatibilité ascendante.

0x0101 Nom du service
Ce TAG indique qu'un nom de service le suit. Sa valeur est une chaine UTF-8 (N.D.T. UTF-8 inclus l'ASCII) qui n'est pas terminée par un caractère nul. Quand sa longueur est de zéro ce TAG indique que n'importe quel service convient. Par exemple, l'utilisation du TAG « Nom du service » peut indiquer le nom d'un ISP (Fournisseur d'accès internet) ou une classe ou une qualité de service.

0x0102 Concentrateur d'accès-Nom
Ce TAG indique que la chaine de caractères qui suit indentifie de manière univoque ce concentrateur d'accès particulier parmi d'autres. Ce peut être une combinaison de marques de fabrique, modèle, et numéros de série, ou plus simplement une transposition UTF-8 de l'adresse MAC du boitier. Elle n'est pas terminée par un caractère nul.

0x0103 Hôte-Identificateur
Ce TAG est utilisé par un hôte pour associer de manière univoque la réponse d'un concentrateur d'accès (PADO ou PADS) à une requête donnée de l'hôte (PADI ou PADR). Sa valeur contient n'importe quelle valeur binaire sur une longueur choisie par l'hôte. Il n'est pas intreprété par le concentrateur d'accès. L'hôte peut inclure un TAG « Hôte-Identificateur » dans un PADI ou un PADR. Si le concentrateur d'accès reçoit ce TAG, il doit l'inclure sans modification dans la réponse PADO ou PADS associée.

0x0104 Concentrateur d'accès-Cookie
Ce TAG est utilisé par le concentrateur d'accès comme une aide à la protection contre des attaques par denie de service (Voir la section sur les considérations de sécurité pour plus d'explications sur son fonctionnement.). Le concentrateur d'accès peut inclure ce TAG dans un paquet PADO. Si un hôte reçoit ce TAG, il doit retourner le TAG sans modification dans le PADR suivant. Sa valeur contient n'importe quelle valeur binaire de n'importe quelle longueur et n'est pas interprété par l'hôte.

0x0105 Spécifications-Fabriquant
Ce TAG est utilisé pour passer des informations propriétaires du fabriquant. Les quatres premiers octets de sa valeur contiennent l'identificateur du fabriquant et le reste n'est pas spécifié. L'octet de poids fort de l'identificateur du fabriquant est 0 et les 3 octets de poids faibles contiennent dans l'ordre de transmission le code « SMI Entreprise privée de gestion du réseau » du fabricant tel que défini dans la RFC « Numéros affectés » [4].
L'usage de ce TAG n'est pas recommandé. Pour assurer un inter-fonctionnement, une implémentation peut discrétement ignorer un TAG « Spécifications-Fabriquant ».

0x0110 Identificateur de session relais
Ce TAG peut être ajouté à n'importe quel paquet de découverte par un agent intermédiaire qui relaie le trafic. Sa valeur est occultée aussi bien pour l'hôte que pour le concentrateur d'accès. Si l'hôte ou le concentrateur d'accès reçois ce TAG, il doit l'inclure sans modification dans tout paquet de découverte qu'il envoie en réponse. Tous les paquets PADI doivent ménager une place suffisante pour l'ajout d'un TAG « Identificateur de session relais » avec une longueur de valeur de 12 octets.
Un TAG « Identificateurde session relais » ne doit pas être ajouté si le paquet de découverte en contient déjà un. Dans ce cas, l'agent intermédiaire doit utiliser le TAG « Identificateur de session relais » existant.S'il ne peut pas utiliser le TAG existant ou qu'il n'y a pas assez de place pour ajouter le TAG « Identificateur de session relais », alors il doit retourner un TAG « Erreur générique » à l'expéditeur.

0x0201 Nom du service-Erreur
Ce TAG (Qui a typiquement une section de donnée de longueur nulle) indique que pour une raison ou une autre la requête « nom du service » ne peut être honorée.
S'il y a des données et que le premier octet de donné n'est pas zéro, alors cela doit être une chaine UTF-8 affichable qui explique pourquoi la requête a été refusée. Cette chaine ne peut pas être terminée par un caractère nul.

0x0202 Concentrateur d'accès-Erreur
Ce TAG indique que le concentrateur d'accès rencontre des erreurs pour effectuer la requête de l'hôte. (Par exemple, des ressources insuffisantes pour créer un circuit virtuel). Il peut être inclus dans des paquets PADS.
S'il y a des données et que le premier octet de donné n'est pas zéro, alors cela doit être une chaine UTF-8 affichable qui explique la nature de l'erreur. Cette chaine ne peut pas être terminée par un caractère nul.

0x0203 Erreur générique
Ce TAG indique une erreur. Il peut être ajouté à des paquets PADO, PADR ou PADS quand une erreur irrécupérable se produit et qu'aucun autre TAG d'erreur ne convient.S'il y a des données alors cela doit être une chaine UTF-8 affichable qui explique la nature de l'erreur. Cette chaine ne doit pas être terminée par un caractère nul.

13. Annexe B

Voici quelques exemples de paquets :

Un paquet PADI :

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
0xffffffff
0xffff																Adresse MAC de l'hôte
Adresse MAC de l'hôte (suite)
Type ethernet = 0x8863																Version = 1				Type = 1				Code = 0x09
Identificateur de session = 0x0000																Longueur = 0x0004
Type de TAG = 0x0101																Longueur du TAG = 0x0000

Un paquet PADO :

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Adresse MAC de l'hôte
Adresse MAC de l'hôte (suite)																Adresse MAC du concentrateur d'accès
Adresse MAC du concentrateur d'accès (suite)
Type ethernet = 0x8863																Version = 1				Type = 1				Code = 0x07
Identificateur de session = 0x0000																Longueur = 0x0020
Type de TAG = 0x0101																Longueur du TAG = 0x0000
Type de TAG = 0x0102																Longueur du TAG = 0x0018
0x47								0x6f								0x20								0x52
0x65								0x64								0x42								0x61
0x63								0x6b								0x20								0x2d
0x20								0x65								0x73								0x68
0x73								0x68								0x65								0x73
0x68								0x6f								0x6f								0x74

Un paquet PPP LCP : La valeur du champ « protocole PPP » est montrée (0xc021) mais pas la charge utile PPP. C'est un paquet de l'hôte vers le concentrateur d'accès.

0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Adresse MAC du concentrateur d'accès
Adresse MAC du concentrateur d'accès (suite)																Adresse MAC de l'hôte
Adresse MAC de l'hôte (suite)
Type ethernet = 0x8864																Version = 1				Type = 1				Code = 0x07
Identificateur de session = 0x1234																Longueur = 0x????
Protocole PPP = 0xc021																Charge utile PPP ...												...

14. Adresses des auteurs

Louis Mamakos
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
Email : louie@uu.net

Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
Email : lidl@uu.net

Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
Email : jde@uu.net

David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
Email : carrel@RedBack.net

Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
Email : dan@RedBack.net

Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212
Newport Beach, CA 92660
United States of America
Email:  ross@routerware.com

15. Copyright intégral

Copyright © The Internet Society (1999). Tous Droits Réservés.

Le document anglais original et les traductions de celui-ci peuvent être copiés et fournis à d'autres, et les travaux dérivés qui le commente ou l'explique ou facilite son implémentation peuvent être préparés, copiés, publiés ou distribués, en totalité ou en partie, sans aucunes restrictions tant que les observations ci-dessus sur le copyright et ce paragraphe sont inclus dans tous ces types de copies ou de travaux dérivés. Cependant, le document anglais original lui-même ne peut être modifié de quelque façon que ce soit, comme par exemple en retirant les observations de copyright ou les références à la Internet Society ou aux autres organismes de l'Internet, excepté comme l'exige le but du développement des standards Internet où dans un tel cas les procédures pour les copyrights définis dans le processus des Standards Internet doivent être suivies, ou alors comme l'exige une traduction dans une langue autre que l'Anglais.

Les autorisations limitées accordées ci-dessus sont éternelles et ne pourrons être révoquées par la Internet Society, ses successeurs ou ses repreneurs.

Ce document et les informations contenues ici sont fournis de façon «  TELS QUELS «  et les traducteurs, la Internet Society et la Internet Engineering Task Force déclinent toute garantie, explicites ou implicites, y compris mais pas seulement toute garantie que l'utilisation des informations de ce document ne violera pas des réglementations ou des garanties implicites commerciales ou physiques pour une application particulière.

L'édition des RFC est actuellement réalisé par l'Internet Society.

Commentaires/Questions à propos de ce document ? Envoyez un émail (N.D.T. en anglais !) à rfc-admin@faqs.org