Groupe de travail Réseau |
W. Townsley, A. Valencia, cisco Systems |
Request for Comments : 2661 |
A. Rubens, Ascend Communications |
Catégorie : En cours de normalisation |
G. Pall, G. Zorn, Microsoft Corporation |
|
B. Palter, Redback Networks |
Traduction Claude Brière de L'Isle |
août 1999 |
Protocole de tunnelage de couche 2 "L2TP"
Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
Notice de Copyright
Copyright (C) The Internet Society (1999). Tous droits réservés.
Résumé
Le présent document décrit le protocole de tunnelage de couche deux (L2TP, Layer Two Tunneling Protocol). La STD 51, RFC 1661 spécifie l'accès multi protocole via PPP [RFC1661]. L2TP facilite le tunnelage des paquets PPP à travers un réseau intervenant d'une façon aussi transparente que possible à la fois pour les utilisateurs finaux et les applications.
Table des Matières
1.1 Spécification des exigences
3.2 Types de messages de commande
4. Messages de commande de paires Attribut-Valeur
4.3 Dissimulation des valeurs d'attribut d'AVP
4.4.1 AVP applicables à tous les messages de commande
4.4.2 Codes de résultat et d'erreur
4.4.3 AVP de gestion de connexion de contrôle
4.4.5 Mandataire LCP et AVP d'authentification
5. Fonctionnement du protocole
5.1 Établissement d'une connexion de contrôle
5.1.1 Authentification de tunnel
5.2.1 Établissement d'appel entrant
5.2.2 Établissement d'appel sortant
5.3 Transmission des trames PPP
5.4 Utilisation des numéros de séquence sur le canal de données
5.7 Suppression de connexion de contrôle
5.8 Livraison fiable des messages de commande
6. Spécification du protocole de connexion de contrôle
6.1 Demande de début de connexion de contrôle (SCCRQ)
6.2 Réponse de début de connexion de contrôle (SCCRP)
6.3 Début de connexion de contrôle connecté (SCCCN)
6.4 Notification d'arrêt de connexion de contrôle (StopCCN)
6.6 Demande d'appel entrant (ICRQ)
6.7 Réponse à appel entrant (ICRP)
6.8 Appel entrant connecté (ICCN)
6.9 Demande d'appel sortant (OCRQ)
6.10 Réponse d'appel sortant (OCRP)
6.11 Appel sortant connecté (OCCN)
6.12 Notification d'appel déconnecté (CDN)
6.13 Notification d'erreur de (WEN)
6.14 Informations d'établissement de liaison (SLI)
7. Automate à états de connexion de contrôle7.1 Fonctionnement du protocole de connexion de contrôle
7.2 États de connexion de contrôle
7.2.1 Établissement de connexion de contrôle
7.3 Considérations de temporisation
7.4.1 États d'appel entrant au LAC
7.4.2 États d'appel entrant au LNS
7.5.1 États d'appel sortant au LAC
7.5.2 États d'appel sortant au LNS
8. L2TP sur supports spécifiques
9. Considérations pour la sécurité
9.1 Sécurité de point d'extrémité de tunnel
9.5 Authentification de mandataire PPP
10. Considérations relatives à l'IANA
10.2 Valeurs d'AVP Type de message
10.3 Valeurs d'AVP Code de résultat
10.3.1 Valeurs du champ Code de résultat
10.3.2 Valeurs du champ Code d'erreur
10.4 Capacités de tramage et capacités du support
10.5 Valeurs d'AVP Type d'authentification de mandataire
Appendice A Démarrage lent et évitement d'encombrement du canal de contrôle
Appendice B Exemples de message de commande
B.1 Établissement de tunnel verrouillé
B.2 Paquet perdu avec retransmission
Appendice C : Notice de propriété intellectuelle
PPP [RFC1661] définit un mécanisme d'encapsulation pour le transport de paquets multi protocoles à travers des liaisons point à point de couche 2 (L2). Normalement, un usager obtient une connexion L2 à un serveur d'accès au réseau (NAS, Network Access Server) en utilisant une des nombreuses techniques existantes (par exemple, la numérotation téléphonique traditionnelle, le RNIS, l'ADSL, etc.) puis de faire fonctionner PPP sur cette connexion. Dans une telle configuration, le point de terminaison L2 et le point d'extrémité PPP résident sur le même appareil physique (c'est-à-dire, le NAS).
L2TP étend le modèle PPP en permettant aux points d'extrémité L2 et PPP de résider sur des appareils différents interconnectés par un réseau à commutation de paquets. Avec L2TP, un usager a une connexion L2 à un concentrateur d'accès (par exemple, un banc de modem, un DSLAM ADSL, etc.) et le concentrateur tunnelle ensuite les trames PPP individuelles au NAS. Cela permet que le traitement réel des paquets PPP soit séparé de la terminaison du circuit L2.
Un avantage évident d'une telle séparation est qu'au lieu d'exiger que la connexion L2 se termine au NAS (ce qui peut impliquer une redevance d'appel interurbain) la connexion peut se terminer sur un concentrateur de circuit local, qui étend alors la session PPP logique sur une infrastructure partagée telle qu'un circuit de relais de trame ou l'Internet. Du point de vue de l'usager, il n'y a pas de différence fonctionnelle entre le fait que le circuit L2 se termine directement dans un NAS ou en utilisant L2TP.
L2TP peut aussi résoudre le problème du partage du faisceau de recherche multi ligne. Le multiligne point à point [RFC1990] exige que tous les canaux qui composent un faisceau multiligne soient groupés à un seul serveur d'accès réseau (NAS). Du fait de sa capacité à projeter une session PPP dans une localisation autre que le point où elle est physiquement reçue, L2TP peut être utilisé pour faire terminer tous les canaux à un seul NAS. Cela permet un fonctionnement multiligne même lorsque les appels sont dispersés sur des NAS distincts physiquement.
Le présent document définit le protocole de commande nécessaire pour la création à la demande de tunnels entre deux nœuds et l'encapsulation qui l'accompagne pour le multiplexage de plusieurs sessions PPP tunnelées.
1.1 Spécification des exigences
Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].
Canal analogique
Chemin d'une communication par circuit commuté destinée à porter 3,1 kHz de données audio dans chaque direction.
Paire Attribut Valeur (AVP)
Enchaînement de longueur variable d'un unique attribut (représenté par un entier) et d'une valeur contenant la valeur réelle identifiée par l'attribut. Plusieurs AVP constituent des messages de commande qui sont utilisés pour l'établissement, l'entretien et la suppression des tunnels.
Appel
Connexion (ou tentative de connexion) entre un système distant et un concentrateur d'accès L2TP (LAC). Par exemple, un appel téléphonique à travers le RTCP. Un appel (entrant ou sortant) dont l'établissement est réussi entre un système distant et un LAC résulte en une session L2TP correspondante au sein d'un tunnel préalablement établi entre le LAC et le LNS. (Voir aussi : Session, Appel entrant, Appel sortant, LAC et LNS).
Numéro demandé
Indication au receveur d'un appel du numéro de téléphone que l'appelant a utilisé pour l'atteindre.
Numéro appelant
Indication au receveur d'un appel du numéro de téléphone de l'appelant.
CHAP
Protocole d’authentification par dialogue à énigme (Challenge Handshake Authentication Protocol) [RFC1994], protocole d'authentification par question/réponse cryptographique en point à point dans lequel le mot de passe en clair n'est pas passé sur la ligne.
Connexion de contrôle
Une connexion de contrôle fonctionne dans la bande sur un tunnel pour contrôler l'établissement, la libération et la maintenance des sessions et du tunnel lui-même.
Messages de commande
Les messages de commande sont échangés entre paires de LAC et de LNS, fonctionnant dans la bande au sein du protocole du tunnel. Les messages de commande gouvernent les aspects du tunnel et des sessions au sein du tunnel.
Canal numérique
Chemin de communication à commutation de circuit qui est destiné à porter des informations numériques dans chaque direction.
DSLAM
Module d'accès de ligne numérique d'abonne (Digital Subscriber Line (DSL) Access Module). Appareil du réseau utilisé dans le déploiement du service DSL. C'est normalement un concentrateur de lignes DSL individuelles localisé dans un bureau central (CO) ou un commutateur local.
Appel entrant
Appel reçu à un LAC pour être tunnelé à un LNS (voir Appel, Appel sortant, LAC, LNS).
LAC (L2TP Access Concentrator) : concentrateur d'accès L2TP
C'est un nœud qui agit comme un côté d'un point d'extrémité de tunnel L2TP et est un homologue du serveur réseau L2TP (LNS, L2TP Network Server). Le LAC se tient entre un LNS et un système distant et transmet les paquets de et vers l'un et l'autre. Les paquets envoyés du LAC au LNS exigent le tunnelage avec le protocole L2TP comme défini dans le présent document. La connexion du LAC au système distant est soit locale (voir LAC client) soit une liaison PPP.
LNS (L2TP Network Server) : serveur réseau L2TP
C'est un nœud qui agit comme un côté d'un point d'extrémité de tunnel L2TP et est un homologue du concentrateur d'accès L2TP (LAC). Le LNS est le point de terminaison logique d'une session PPP qui est tunnelée du système distant par le LAC.
Domaine de gestion (MD, management domain)
C'est un ou des réseaux sous le contrôle d'une seule administration, politique ou système. Par exemple, le domaine de gestion d'un LNS pourrait être le réseau de l'entreprise qu'il dessert. Le domaine de gestion d'un LAC pourrait être le fournisseur de service Internet qui le possède et le gère.
NAS (Network Access Server) : serveur d'accès réseau
Appareil qui fournit l'accès au réseau local aux usagers à travers un réseau d'accès distant tel que le RTPC. Un NAS peut aussi servir de LAC, de LNS, ou les deux.
Appel sortant
Appel passé par un LAC au nom d'un LNS (voir Appel, Appel sortant, LAC, LNS).
Homologue
Utilisé dans le contexte de L2TP, homologue se réfère au LAC ou au LNS. L'homologue d'un LAC est un LNS et vice versa. Utilisé dans le contexte de PPP, un homologue est l'un ou l'autre côté de la connexion PPP.
POTS (Plain Old Telephone Service)
Le service téléphonique traditionnel.
Système distant
Un système d'extrémité ou un routeur rattaché à un réseau d'accès distant (c'est-à-dire un RTPC) qui est soit l'initiateur soit le receveur d'un appel. Aussi appelé un client de numérotation ou client virtuel de numérotation.
Session
L2TP est orienté connexion. Le LNS et le LAC maintiennent l'état de chaque appel qui est généré ou reçu par un LAC. Une session L2TP est créée entre le LAC et le LNS lorsque une connexion PPP de bout en bout est établie entre un système distant et le LNS. Les datagrammes qui se rapportent à la connexion PPP sont envoyés sur le tunnel entre le LAC et le LNS. Il y a une relation biunivoque entre les sessions L2TP établies et leurs appels associés. (voir aussi Appel).
Tunnel
Un tunnel existe entre une paire LAC-LNS. Le tunnel consiste en une connexion de contrôle et zéro, une ou plusieurs sessions L2TP. Le tunnel porte des datagrammes PPP encapsulés et des messages de commande entre le LAC et le LNS.
Message de longueur de corps zéro (ZLB, Zero-Length Body)
Paquet de contrôle avec seulement un en-tête L2TP. Les messages ZLB sont utilisés pour accuser explicitement réception des paquets sur le canal de contrôle fiable.
Le diagramme suivant décrit un scénario L2TP typique. Le but est de tunneler des trames PPP entre le système distant ou le client LAC et un LNS localisé à un LAN de rattachement.
[LAN de rattachement]
[Client LAC]----------+ |
____|_____ +--[Hôte]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| Nuage |
[Système]--| RTPC |
[distant] | | [LAN de rattachement]
|__________| _______________ |
| | | +---[Hôte]
| | Nuage | |
[LAC]-------| relais de |---[LNS]-----+
| trame ou ATM | |
|______________| :
Le système distant initie une connexion PPP avec un LAC à travers le nuage RTPC. Le LAC tunnelle alors la connexion PPP à travers le nuage Internet, relais de trame ou ATM vers un LNS par quoi est obtenu l'accès à un LAN de rattachement. Le système distant reçoit des adresses du LAN de rattachement via la négociation NCP (protocole de commande réseau) de PPP. L'authentification, l'autorisation et la comptabilité peuvent être fournies par le domaine de gestion du LAN de rattachement comme si l'usager était connecté directement à un serveur d'accès réseau.
Un client LAC (un hôte qui fonctionne d'origine avec L2TP) peut aussi participer au tunnelage au LAN de rattachement sans utiliser un LAC séparé. Dans ce cas, l'hôte qui contient le logiciel de client LAC a déjà une connexion à l'Internet public. Une connexion PPP "virtuelle" est alors créée et le logiciel de client LAC du L2TP local crée un tunnel pour le LNS. Comme dans le cas précédent, adressage, authentification, autorisation et comptabilité seront fournis par le domaine de gestion du LAN de rattachement.
L2TP utilise deux types de messages, les messages de commande et les messages de données. Les messages de commande sont utilisés pour l'établissement, l'entretien et la libération des tunnels et des appels. Les messages de données sont utilisés pour encapsuler les trames PPP qui sont transportées sur le tunnel. Les messages de commande utilisent un canal de contrôle fiable au sein de L2TP pour garantir la livraison (voir les détails au paragraphe 5.1). Les messages de données ne sont pas retransmis si une perte de paquet survient.
+-----------------------+
| Trames PPP |
+-----------------------+ +-------------------------+
|Message de données L2TP| |Message de commande L2TP |
+-----------------------+ +-------------------------+
| Canal de données L2TP | | Canal de contrôle L2TP |
| (non fiable) | | (fiable) |
+-----------------------------------------------------+
| Transport de paquets(UDP, FR, ATM, etc.) |
+-----------------------------------------------------+
Figure 3. : Structure du protocole L2TP
La Figure 3. décrit les relations des trames PPP et des messages de commande sur les canaux de commande et de données L2TP. Les trames PPP sont passées sur un canal de données non fiable en étant d'abord encapsulées par un en-tête L2TP puis par un transport de paquet tel que UDP, relais de trame, ATM, etc. Les messages de commande sont envoyés sur un canal de contrôle L2TP fiable qui transmet les paquets dans la bande sur le même transport de paquets.
Les numéros de séquence doivent obligatoirement être présents dans tous les messages de commande et sont utilisés pour assurer une livraison fiable sur le canal de contrôle. Les messages de données peuvent utiliser des numéros de séquence pour réarranger les paquets et détecter les paquets perdus.
Toutes les valeurs sont placées dans leurs champs respectifs et envoyées dans l'ordre du réseau (octets de poids fort en premier).
Les paquets L2TP pour le canal de contrôle et le canal de données ont un format d'en-tête commun. Dans tous les cas de champ facultatif, son espace n'existe pas dans le message si le champ est marqué non présent. Noter que bien que facultatifs dans les messages de données, les champs Longueur, Ns, et Nr marqués facultatifs ci-dessous sont obligatoirement présents sur tous les messages de commande.
Format de l'en-tête :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Longueur (facultatif) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de tunnel | Identifiant de session |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (fac) | Nr (fac) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Taille de décalage (fac) | Bourrage de décalage... (fac)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.1 : En-tête de message L2TP
Le bit Type (T) indique le type du message. Il est mis à 0 pour un message de données et à 1 pour un message de commande.
Si le bit Longueur (L) est mis à 1, le champ Longueur est présent. Ce bit DOIT être mis à 1 pour les messages de commande.
Les bits x sont réservés pour des extensions futures. Tous les bits réservés DOIVENT être mis à 0 sur les messages sortants et ignorés sur les messages entrants.
Si le bit Séquence (S) est mis à 1, les champs Ns et Nr sont présents. Le bit S DOIT être mis à 1 pour les messages de commande.
Si le bit Offset (O) (décalage) est 1, le champ Taille de décalage est présent. Le bit O DOIT être mis à 0 (zéro) pour les messages de commande.
Si le bit Priorité (P) est à 1, ce message de données devrait recevoir un traitement préférentiel dans sa mise en file d'attente locale et sa transmission. Les demandes d'écho LCP (Link Control Protocol, protocole de contrôle des liaisons) utilisées par exemple comme maintien en vie de la liaison, devraient généralement être envoyées avec ce bit mis à 1. Sans cela, un intervalle temporaire d'encombrement local pourrait interférer avec les messages de maintien en vie et causer une perte inutile de la liaison. Ce dispositif n'est à utiliser qu'avec les messages de données. Le bit P DOIT être mis à 0 pour tous les messages de commande.
Ver (Version) DOIT être 2, indiquant le numéro de version de l'en-tête du message de données L2TP décrit dans le présent document. La valeur 1 est réservée à permettre la suppression des paquets L2F [RFC2341] qui pourraient arriver mélangés à des paquets L2TP. Les paquets reçus avec un champ Ver inconnu DOIVENT être éliminés.
Le champ Longueur indique la longueur totale du message en octets.
Identifiant de tunnel indique l'identifiant de la connexion de contrôle. Les tunnels L2TP sont désignés par des identifiants qui n'ont qu'une signification locale. C'est à dire que le même tunnel va recevoir un identifiant de tunnel différent à chaque extrémité du tunnel. Dans chaque message, l'identifiant de tunnel est celui du receveur auquel il est destiné, et non celui de l'envoyeur. Les identifiants de tunnel sont choisis et échangés comme paires Attribut-Valeur (AVP) d'identifiant de tunnel alloué lors de la création d'un tunnel.
Identifiant de session indique l'identifiant d'une session au sein d'un tunnel. Les sessions L2TP sont désignées par des identifiants dont la signification est seulement locale. C'est à dire que la même session va recevoir un identifiant de session différent à chaque extrémité de la session. L'identifiant de session de chaque message est celui du receveur auquel il est destiné, et non celui de l'envoyeur. Les identifiants de session sont choisis et échangés comme paires Attribut-Valeur d'identifiant de session alloué lors de la création d'une session.
Ns indique le numéro de séquence pour ce message de données ou de commande, commençant à zéro et s'incrémentant de un (modulo 2**16) pour chaque message envoyé. Voir les paragraphes 5.8 et 5.4 pour plus d'informations sur l'utilisation de ce champ.
Nr indique le numéro de séquence attendu dans le prochain message de commande à recevoir. Et donc, Nr est réglé à Ns du dernier message rangé à sa place reçu, plus un (modulo 2**16). Dans les messages de données, Nr est réservé et, si il est présent (comme indiqué par le bit S) DOIT être ignoré à réception. Voir au paragraphe 5.8 des informations supplémentaires sur l'utilisation de ce champ dans les messages de commande.
Le champ Taille de décalage, s'il est présent, spécifie le nombre d'octets après l'en-tête L2TP auquel les données de charge utile sont censées commencer. Les données réelles qui sont dans le bourrage de décalage ne sont pas définies. Si le champ décalage est présent, l'en-tête L2TP se termine après le dernier octet du bourrage de décalage.
3.2 Types de messages de commande
L'AVP Type de message (voir au paragraphe 4.4.1) définit le type spécifique de message de commande qui est envoyé. On rappelle qu'il est dit au paragraphe 3.1 que c'est seulement pour les messages de commande, c'est à dire les messages avec le bit T mis à 1.
Le présent document définit les types de message de commande suivants (voir des paragraphes 6.1 à 6.14 les détails sur la construction et l'usage de chaque message) :
Gestion de la connexion de contrôle
0 (réservé)
1 (SCCRQ, Start-Control-Connection-Request) Demande de début de connexion de contrôle
2 (SCCRP, Start-Control-Connection-Reply) Réponse de début de connexion de contrôle
3 (SCCCN, Start-Control-Connection-Connected) Début de connexion de contrôle connecté
4 (StopCCN, Stop-Control-Connection-Notification) Notification d'arrêt de connexion de contrôle
5 (réservé)
6 (HELLO) Message d'accueil
Gestion d'appel
7 (OCRQ, Outgoing-Call-Request) Demande d'appel sortant
8 (OCRP, Outgoing-Call-Reply) Réponse à appel sortant
9 (OCCN, Outgoing-Call-Connected) Appel sortant connecté
10 (ICRQ, Incoming-Call-Request) Demande d'appel entrant
11 (ICRP, Incoming-Call-Reply) Réponse d'appel entrant
12 (ICCN, Incoming-Call-Connected) Appel entrant connecté
13 (réservé)
14 (CDN, Call-Disconnect-Notify) Notification de déconnexion de l'appel
Rapport d'erreur
15 (WEN, WAN-Error-Notify) Notification d'erreur de WAN
Contrôle de session PPP
16 (SLI, Set-Link-Info) Informations d'établissement de liaison
4. Messages de commande de paires Attribut-Valeur
Pour maximiser les possibilités d'extension tout en maintenant l'interopérabilité, on utilise une méthode uniforme de codage des types et corps de message dans tout L2TP. Ce codage est appelé AVP (paire Attribut-Valeur) dans la suite de ce document.
Chaque AVP est codé de la façon suivante :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Longueur | Identifiant de fabricant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type d'attribut | Valeur d'attribut ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[jusqu'à atteindre Longueur]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les six premiers bits sont un gabarit binaire, qui décrit les attributs généraux de l'AVP.
Deux bits sont définis dans le présent document, les autres sont réservés pour les extensions futures. Les bits réservés DOIVENT être mis à 0. Un AVP reçu avec un bit réservé mis à 1 DOIT être traité comme un AVP non reconnu.
Le bit M (Mandatory, obligatoire) : il contrôle le comportement requis d'une mise en œuvre qui reçoit un AVP qu'elle ne reconnaît pas. Si le bit M est mis sur une AVP non reconnue au sein d'un message associé à une session particulière, la session associée à ce message DOIT se terminer. Si le bit M est mis sur une AVP non reconnue dans un message associé au tunnel global, tout le tunnel (et toutes les sessions qu'il contient) DOIVENT se terminer. Si le bit M n'est pas mis, une AVP non reconnue DOIT être ignorée. Le message de commande doit alors continuer d'être traité comme si l'AVP n'avait pas été présente.
Le bit H (Hidden, caché) : il identifie la dissimulation de données dans le champ Valeur d'attribut d'une AVP. Cette capacité peut être utilisée pour éviter de passer des données sensibles, telles que des mots de passe d'usager, en clair dans une AVP. Le paragraphe 4.3 décrit la procédure pour effectuer la dissimulation dans une AVP.
Longueur : code le nombre d'octets (y compris les champs Longueur globale et gabarit binaire) contenus dans cette AVP. La Longueur peut être calculée comme 6 + la longueur du champ Valeur d'attribut en octets. Le champ lui-même est de 10 bits, permettant un maximum de 1023 octets de données dans une seule AVP. La longueur minimum d'une AVP est 6. Si la longueur est 6, le champ Valeur d'attribut est alors absent.
Identifiant de fabricant : c'est la valeur allouée par l'IANA de "Codes SMI d'entreprise privée de gestion de réseau" de la [RFC1700]. La valeur 0, qui correspond aux valeurs d'attribut adoptées par l'IETF, est utilisée pour toutes les AVP définies dans le présent document. Tout fabricant qui souhaite mettre en œuvre ses propres extensions L2TP peut utiliser son propre identifiant de fabricant avec ses valeurs d'attribut privées, ce qui garantit qu'elles ne vont pas entrer en collision avec d'autres extensions de fabricant, ni avec de futures extensions de l'IETF. Noter qu'il y a 16 bits d'alloués pour l'identifiant de fabricant, ce qui limite donc cette caractéristique aux 65 535 premières entreprises.
Type d'attribut : c'est une valeur de deux octets avec une interprétation unique parmi toutes les AVP définies sous un identifiant de fabricant donné.
Valeur d'attribut : c'est la valeur réelle indiquée par l'identifiant de fabricant et le type d'attribut. Elle suit immédiatement le champ Type d'attribut, et couvre les octets restants indiqués dans le champ Longueur (c'est-à-dire, Longueur moins 6 octets d'en-tête). Ce champ est absent si Longueur est de 6.
La réception d'une AVP inconnue qui a le bit M mis à 1 est catastrophique pour la session ou le tunnel qui y est associé. Et donc, le bit M ne devrait être défini que pour les AVP qui sont absolument cruciales pour le bon fonctionnement de la session ou du tunnel. De plus, dans le cas où le LAC ou le LNS reçoit une AVP inconnue avec le bit M mis et clôt en conséquence la session ou le tunnel, il est de l'entière responsabilité de l'homologue qui envoie l'AVP obligatoire d'accepter une faute pour avoir causé une situation non interopérable. Avant de définir une AVP avec le bit M établi, en particulier une AVP spécifique de fabricant, assurez vous que c'est bien la conséquence voulue.
Lorsqu'il existe une solution de remplacement adéquate pour l'utilisation du bit M, elle devrait être utilisée. Par exemple, plutôt que simplement envoyer une AVP avec le bit M établi pour déterminer si une extension spécifique existe, la disponibilité peut être identifiée par l'envoi d'une AVP dans un message de demande et d'attendre une AVP correspondante dans un message de réponse.
L'utilisation du bit M avec de nouvelles AVP (celle qui ne sont pas définies dans le présent document) DOIT donner la possibilité de configurer la caractéristique associée, de telle sorte que l'AVP soit non envoyée, ou envoyée avec le bit M non établi.
4.3 Dissimulation des valeurs d'attribut d'AVP
Le bit H dans l'en-tête de chaque AVP donne un mécanisme pour indiquer à l'homologue receveur si le contenu de l'AVP est caché ou présent en clair. Ce dispositif peut être utilisé pour cacher des données sensibles de message de commande telles que des mots de passe d'utilisateur ou des identifiants d'usager.
Le bit H ne DOIT être établi que si un secret partagé existe entre le LAC et le LNS. Le secret partagé est le même secret que celui qui est utilisé pour l'authentification de tunnel (voir au paragraphe 5.1.1). Si le bit H est mis dans une ou des AVP dans un message de commande donné, une AVP Vecteur aléatoire doit aussi être présente dans le message et DOIT précéder la première AVP qui a un bit H de 1.
Cacher une valeur d'AVP se fait en plusieurs étapes. La première étape est de prendre les champs de longueur et de valeur de l'AVP d'origine (en clair) et de les coder en sous format AVP caché comme suit :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Longueur de la valeur d'origine|Valeur de l'attribut d'origine...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Bourrage ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Longueur de la valeur d'attribut d'origine : c'est la longueur en octets de la valeur d'attribut d'origine à dissimuler. Elle est nécessaire pour déterminer la longueur originale de la valeur d'attribut qui est perdue lorsque le bourrage supplémentaire est ajouté.
Valeur de l'attribut d'origine : c'est la valeur de l'attribut à dissimuler.
Bourrage : octets supplémentaires aléatoires utilisés pour dissimuler la longueur de la valeur de l'attribut qui va être caché.
Pour masquer la taille des données à cacher, le sous format résultant PEUT être bourré comme montré ci-dessus. Le bourrage N'altère PAS la valeur placée dans le champ Longueur de valeur de l'attribut d'origine, mais altère la longueur de l'AVP résultante qui est crée. Par exemple, si une valeur d'attribut à cacher est longue de quatre octets, la longueur non cachée de l'AVP serait de 10 octets (6 + longueur de valeur d'attribut). Après être cachée, la longueur de l'AVP va devenir de 6 + longueur de valeur d'attribut + taille de la longueur du champ Valeur de l'attribut d'origine + bourrage. Et donc, si le bourrage est de 12 octets, la longueur de l'AVP sera de 6 + 4 + 2 + 12 = 24 octets.
Ensuite, un hachage MD5 est effectué sur l'enchaînement de :
+ le numéro d'attribut de deux octets de l'AVP
+ le secret partagé
+ un vecteur aléatoire de longueur arbitraire
La valeur du vecteur aléatoire utilisé dans ce hachage est passée dans le champ valeur d'une AVP de vecteur aléatoire. Cette AVP de vecteur aléatoire doit être placée dans le message par l'envoyeur avant toute AVP cachée. Le même vecteur aléatoire peut être utilisé pour plus d'une AVP cachée dans le même message. Si un vecteur aléatoire différent est utilisé pour cacher des AVP suivantes, une nouvelle AVP de vecteur aléatoire doit alors être placée dans le message de commande avant la première AVP à laquelle il s'applique.
La valeur du hachage MD5 est alors combinée par l'opérateur OUX avec le premier segment de 16 octets (ou moins) du sous format de l'AVP cachée et placée dans le champ Valeur d'attribut de l'AVP cachée. Si le sous format de l'AVP cachée est de moins de 16 octets, le sous format est transformé comme si le champ Valeur d'attribut avait été bourré à 16 octets avant le OUX, mais seuls les octets réels présents dans le sous format sont modifiés, et la longueur de l'AVP n'est pas altérée.
Si le sous format est plus long que 16 octets, un second hachage MD5 unidirectionnel est calculé sur un flux d'octets comportant le secret partagé suivi du résultat du premier OUX. Ce hachage est combiné par l'opérateur OUX avec le second segment de 16 octets (ou moins) du sous format et placé dans les octets correspondants du champ Valeur de l'AVP cachée.
Si nécessaire, cette opération est répétée, avec le secret partagé utilisé avec chaque résultat de OUX pour générer le prochain hachage pour le combiner par l'opérateur OUX avec le prochain segment de la valeur.
La méthode de dissimulation a été adaptée de la [RFC2138] qui l'avait tirée du chapitre "Mixing in the Plaintext" dans le livre "Network Security" de Kaufman, Perlman et Speciner [KPS]. Voici une explication détaillée de la méthode :
Appelons S le secret partagé, RV le vecteur aléatoire, et AV la valeur d'attribut. Partageons le champ de valeur en tronçons de 16 octets p1, p2, etc. dont le dernier est bourré à la fin de données aléatoires jusqu'à une frontière de 16 octets. Appelons les blocs de texte chiffré c(1), c(2), etc. Nous allons aussi définir des valeurs intermédiaires b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 oux b1
b2 = MD5(S + c(1)) c(2) = p2 oux b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi oux bi
La chaîne va contenir c(1) + c(2) +... + c(i), où + note l'enchaînement.
À réception, le vecteur aléatoire est tiré de la dernière AVP Vecteur aléatoire rencontrée dans le message avant l'AVP à cacher. Le processus ci-dessus est alors renversé pour donner la valeur d'origine.
Les paragraphes qui suivent contiennent la liste de toutes les AVP L2TP définies dans ce document.
Après le nom de l'AVP se trouve une liste indiquant les types de message qui utilisent chaque AVP. Après le titre de chaque AVP suit une brève description de l'objet de l'AVP, le détail (comportant un graphique) du format de la valeur d'attribut, et toutes les informations supplémentaires nécessaires pour un bon usage de l'AVP.
Type de message : tous les messages
AVP Type de message, type d'attribut 0, identifie le message de commande qui est là et définit le contexte dans lequel la signification exacte des AVP suivantes sera déterminée.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type de message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type de message est un entier non signé de deux octets.
L'AVP Type de message DOIT être la première AVP d'un message, suivant immédiatement l'en-tête du message de commande (défini au paragraphe 3.1). Voir au paragraphe 3.2 la liste des types de message de commande définis et leurs identifiants.
Le bit M (Obligatoire) a une signification particulière au sein de l'AVP Type de message. Plutôt que d'une indication que l'AVP elle-même devrait être ignorée si elle n'est pas reconnue, elle indique si le message de commande lui-même devrait être ignoré. Et donc, si le bit M est mis dans l'AVP Type de message et si le type de message est inconnu de la mise en œuvre, le tunnel DOIT être éliminé. Si le bit M n'est pas établi, la mise en œuvre peut alors ignorer un type de message inconnu. Le bit M DOIT être mis à 1 pour tous les types de message définis dans ce document. Cette AVP ne peut pas être caché (le bit H DOIT être 0). La longueur de cette AVP est 8.
Vecteur aléatoire (tous messages)
L'AVP Vecteur aléatoire, Type d'attribut 36, est utilisé pour permettre de cacher la valeur d'attribut d'AVP arbitraires.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chaîne d'octets aléatoire ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La chaîne d'octets aléatoire peut être de longueur arbitraire, bien qu'un vecteur aléatoire d'au moins 16 octets soit recommandé. La chaîne contient le vecteur aléatoire à utiliser pour calculer le hachage MD5 pour restituer ou cacher la valeur d'attribut d'une AVP cachée (voir au paragraphe 4.2).
Plus d'une AVP Vecteur aléatoire peut apparaître dans un message, auquel cas une AVP cachée utilise l'AVP Vecteur aléatoire la plus proche qui la précède. Cette AVP DOIT précéder la première AVP qui a le bit H mis.
Le bit M pour cette AVP DOIT être mis à 1. Cette AVP NE DOIT PAS être cachée (le bit H DOIT être à 0). La longueur de cette AVP est 6 plus la longueur de la chaîne d'octets aléatoire.
Code de résultat (CDN, StopCCN)
L'AVP Code de résultat, type d'attribut 1, indique la raison de la fin du canal de contrôle ou de la session.
Le champ Valeur d'attribut pour cette AVP a le format suivant:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code de résultat | Code d'erreur (fac) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message d'erreur (fac) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Code de résultat est un entier non signé de deux octets. Le Code d'erreur facultatif est un entier non signé de deux octets. Un message d'erreur facultatif peut suivre le champ Code d'erreur. La présence du code d'erreur et du message d'erreur est indiquée par le champ Longueur d'AVP. Le message d'erreur contient une chaîne arbitraire qui donne un texte supplémentaire (lisible par l'homme) associé à la condition. Le texte lisible du message d'erreur DOIT être fourni dans le jeu de caractères UTF-8 en utilisant le langage par défaut de la [RFC2277].
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La Longueur est 8 si il n'y a pas de code ou message d'erreur, 10 si il y a un code d'erreur et pas de message d'erreur ou 10 + la longueur du message d'erreur si il y a un code et un message d'erreur.
Les valeurs de code de résultat définies pour le message StopCCN sont :
0 - Réservé
1 – Demande générale de libérer la connexion de contrôle
2 – Erreur générale -- le code d'erreur indique le problème
3 – Le canal de contrôle existe déjà
4 – Le demandeur n'est pas autorisé à établir un canal de contrôle
5 – La version de protocole du demandeur n'est pas acceptée, le code d'erreur indique la plus forte version acceptée
6 – Le demandeur est en train de fermer
7 – Erreur d'automate à états
Valeurs de codes de résultat définis pour le message CDN :
0 - Réservé
1 - Appel déconnecté suite à la perte de la porteuse
2 - Appel déconnecté pour la raison indiquée dans le code d'erreur
3 - Appel déconnecté pour des raisons administratives
4 – Échec d'appel faute de disponibilité des facilités appropriées (condition temporaire)
5 - Échec d'appel faute de disponibilité des facilités appropriées (condition permanente)
6 – Destination invalide
7 - Échec d'appel, pas de porteuse détectée
8 - Échec d'appel sur détection d'un signal d'occupation
9 - Échec d'appel faute de tonalité
10 – L'appel n'a pas été établi dans le délai alloué par le LAC
11 – L'appel a été connecté mais aucun tramage approprié n'a été détecté
Les codes d'erreur définis ci-dessous appartiennent à des types d'erreurs qui ne sont pas spécifiques d'une demande L2TP particulière, mais plutôt d'erreurs de protocole ou de format de message. Si une réponse L2TP indique dans son code de résultat qu'une erreur générale est survenue, la valeur d'erreur générale devrait être examinée pour déterminer quelle était l'erreur. Les codes d'erreur générale actuellement définis et leurs significations sont :
0 – Pas d'erreur générale
1 – Aucune connexion de contrôle n'existe pour cette paire LAC-LNS
2 – Longueur est erronée
3 - Une des valeurs de champ est hors gamme ou un champ réservé n'est pas à zéro
4 – Ressources insuffisantes pour traiter cette opération pour l'instant
5 – L'identifiant de session est invalide dans ce contexte
6 - Une erreur générique spécifique du fabricant est survenue dans le LAC
7 - Essayer un autre. Si le LAC connaît d'autres destinations de LNS possibles, il devrait en essayer une. Cela peut être utilisé pour guider un LAC sur la base de la politique du LNS, par exemple, l'existence de faisceaux PPP multiligne.
8 – La session ou le tunnel a été clos sur réception d'une AVP inconnue avec le bit M mis (voir au paragraphe 4.2). Le message d'erreur DEVRAIT contenir l'attribut de l'AVP fautive sous forme textuelle (lisible par l'homme).
Lorsque un code d'erreur générale de 6 est utilisé, des informations supplémentaires sur l'erreur DEVRAIENT être incluses dans le champ Message d'erreur.
Version de protocole (SCCRP, SCCRQ)
AVP Version de protocole, type d'attribut 2, indique la version du protocole L2TP de l'envoyeur.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Révision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le champ Version est un entier non signé de un octet qui contient la valeur 1. Le champ Révision est un entier non signé de un octet qui contient 0. Cela indique la version 1, révision 0 du protocole L2TP. Noter que ceci n'est pas le même numéro de version que celui qui est inclus dans l'en-tête de chaque message.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 8.
Capacités de tramage (SCCRP, SCCRQ)
L'AVP Capacités de tramage, type d'attribut 3, donne à l'homologue une indication des types de tramage qui seront acceptés ou demandés par l'envoyeur.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé pour de futures définitions de type de tramage |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le champ Valeur d'attribut est un gabarit binaire de 32 bits, avec deux bits définis. Si le bit A est mis, le tramage asynchrone est accepté. Si le bit S est mis, le tramage synchrone est pris en charge.
Un homologue NE DOIT PAS demander un appel entrant ou sortant avec une AVP Type de tramage qui spécifie une valeur non annoncée dans l'AVP Capacités de tramage reçue durant l'établissement de la connexion de contrôle. L'appel qui tenterait de le faire doit être rejeté.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) est 10.
Capacités support (SCCRP, SCCRQ)
L'AVP Capacités support, type d'attribut 4, donne à l'homologue l'indication des types d'appareil support acceptés par les interfaces matérielles de l'envoyeur pour les appels sortants.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé pour de futures définitions de type de support |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C'est un gabarit de 32 bits, avec deux bits définis. Si le bit A est mis, l'accès analogique est accepté. Si le bit D est mis, l'accès numérique est pris en charge.
Un LNS ne devrait pas demander un appel sortant qui spécifie une valeur dans l'AVP Type de support pour un type d'appareil non annoncé dans l'AVP Capacités support reçue du LAC durant l'établissement de la connexion de contrôle. L'appel qui tenterait de le faire doit être rejeté.
Cette AVP DOIT être présente si l'envoyeur peut faire des appels sortants lorsque elle est demandée.
Noter qu'un LNS qui ne peut pas aussi agir comme un LAC n'acceptera pas les appareils qui traitent les appels entrants et sortants et devrait donc régler les bits A et D de cette AVP à 0, ou ne devrait pas envoyer du tout cette AVP. Un LNS qui peut aussi agir comme LAC et faire des appels sortants devrait régler A ou D comme approprié. La présence de ce message n'est pas une garantie qu'un appel sortant donné sera effectué par l'envoyeur si cela lui est demandé, mais simplement que la capacité physique existe.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) est 10.
Départage (SCCRQ)
L'AVP Départage, type d'attribut 5, indique que l'envoyeur souhaite qu'un seul tunnel existe entre la paire LAC-LNS donnée.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valeur de départage ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La valeur de Départage est de 8 octet qui est utilisée pour choisir un seul tunnel lorsque le LAC et le LNS demandent tous deux concurremment un tunnel. Le receveur d'une SCCRQ doit vérifier pour voir si une SCCRQ a été envoyée à l'homologue, et si il en est ainsi, il doit comparer sa valeur de départage à celle reçue. La plus faible valeur "gagne", et le "perdant" DOIT éliminer son tunnel en silence. Dans le cas ou le départage est présent des deux côtés, et où la valeur est égale, les deux côtés DOIVENT éliminer leur tunnel.
Si un départage est reçu, et si une SCCRQ en instance n'avait pas de valeur de départage, l'initiateur qui a inclus l'AVP Départage "gagne". Si aucun des deux côté n'a produit de départage, deux tunnels distincts sont ouverts.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 0. La longueur de cette AVP est 14.
Révision de microcode (SCCRP, SCCRQ)
L'AVP Révision de microcode, type d'attribut 6, indique la révision de microcode de l'appareil envoyeur.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Révision de microcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Révision de microcode est un entier non signé de deux octets codé dans un format spécifique du fabricant.
Pour les appareils qui n'ont pas de révision de microcode (par exemple, des ordinateurs non dédiés fonctionnant avec des modules de logiciel L2TP) la révision du module de logiciel L2TP peut être mentionnée à la place.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) est 8.
Nom d'hôte (SCCRP, SCCRQ)
L'AVP Nom d'hôte, type d'attribut 7, indique le nom du LAC ou LNS qui la produit.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nom d'hôte ... (nombre arbitraire d'octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nom d'hôte a une longueur arbitraire, mais DOIT avoir au moins 1 octet.
Ce nom devrait être aussi largement unique que possible ; pour les hôtes qui participent au DNS [RFC1034], un nom d'hôte avec un domaine pleinement qualifié serait approprié.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 6 plus la longueur du nom d'hôte.
Nom de fabricant (SCCRP, SCCRQ)
L'AVP Nom de fabricant, type d'attribut 8, contient une chaîne spécifique du fabricant (éventuellement lisible par l'homme) qui décrit le type de LAC ou LNS utilisé.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nom de fabricant ...(nombre arbitraire d'octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le nom de fabricant a le nombre d'octets indiqué représentant la chaîne du fabricant. Le texte lisible par l'homme pour cette AVP DOIT être fourni dans le jeu de caractères UTF-8 en utilisant le langage par défaut de la [RFC2277].
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur du nom de fabricant.
Identifiant de tunnel alloué (SCCRP, SCCRQ, StopCCN)
L'AVP Identifiant de tunnel alloué, type d'attribut 9, code l'identifiant alloué à ce tunnel par l'envoyeur.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de tunnel alloué |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de tunnel alloué est un entier non signé différent de zéro de deux octets.
L'AVP Identifiant de tunnel alloué établit une valeur utilisée pour multiplexet et démultiplexer plusieurs tunnels entre le LNS et le LAC. L'homologue L2TP DOIT placer cette valeur dans le champ d'en-tête Identifiant de tunnel de tous les messages de commande et de données qu'il transmet ensuite sur le tunnel associé. Avant que l'AVP Identifiant de tunnel alloué soit reçu d'un homologue, des messages DOIVENT être envoyés à cet homologue avec une valeur d'identifiant de tunnel de 0 dans l'en-tête de tous les messages de commande.
Dans le message de commande StopCCN, l'AVP Identifiant de tunnel alloué DOIT être le même que l'AVP Identifiant de tunnel alloué d'abord envoyée à l'homologue receveur, permettant à l'homologue d'identifier le tunnel approprié même si un StopCCN est envoyé avant qu'une AVP Identifiant de tunnel alloué soit reçue.
Cette AVP peur être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 8.
Taille de fenêtre reçue (SCCRQ, SCCRP)
L'AVP Taille de fenêtre reçue, type d'attribut 10, spécifie la taille de la fenêtre reçue offerte à l'homologue distant.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Taille de fenêtre |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taille de fenêtre est un entier non signé de deux octets.
Si elle est absente, l'homologue doit supposer une taille de fenêtre de 4 pour sa fenêtre d'émission. l'homologue distant peut envoyer le nombre spécifié de messages de commande qu'il doit attendre pour un accusé de réception.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 8.
Challenge (SCCRP, SCCRQ)
L'AVP Challenge, type d'attribut 11, indique que l'homologue qui la produit souhaite authentifier les points d'extrémité du tunnel en utilisant un mécanisme d'authentification de style CHAP.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (nombre arbitraire d'octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Challenge comporte un ou plusieurs octets de données aléatoires.
Cette AVP peur être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de Challenge.
Réponse à challenge (SCCCN, SCCRP)
L'AVP Réponse, type d'attribut 13, fournit une réponse au challenge reçu.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réponse ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Réponse est une valeur de 16 octets qui reflète la réponse de style CHAP [RFC1994] au challenge.
Cette AVP DOIT être présente dans une SCCRP ou SCCCN si un challenge a été reçu dans la SCCRQ ou SCCRP précédente. Pour les besoins du calcul de la valeur d'identifiant dans la réponse CHAP, on utilise la valeur de l'AVP Type de message pour ce message (par exemple 2 pour une SCCRP, et 3 pour une SCCCN).
Cette AVP peur être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 22.
Code de cause Q.931 (CDN)
L'AVP Code de cause Q.931, type d'attribut 12, est utilisée pour donner des informations supplémentaires dans le cas de déconnexion involontaire de l'appel.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code de cause | Msg de cause | Msg conseil...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code de cause est le code de cause Q.931 retourné, et Msg de cause est le message de code Q.931 retourné (par exemple, DISCONNECT) associé au code de cause. Les deux valeurs sont retournées dans leur codage UIT d'origine [DSS1]. Un texte ASCII additionnel Message de conseil peut aussi être inclus (présence indiquée par l'AVP Longueur) pour mieux expliquer la raison de la déconnexion.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 9, plus la taille de ce message de conseil.
Identifiant de session alloué (CDN, ICRP, ICRQ, OCRP, OCRQ)
L'AVP Identifiant de session alloué, type d'attribut 14, code l'identifiant qui est alloué à cette session par l'envoyeur.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de session alloué |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de session alloué est un entier non signé différent de zéro de deux octets.
L'AVP Identifiant de session alloué établit une valeur utilisée pour multiplexer et démultiplexer les données envoyées sur un tunnel entre le LNS et le LAC. L'homologue L2TP DOIT placer cette valeur dans le champ d'en-tête Identifiant de session de tout message de commande et de données qui est transmis ensuite sur le tunnel et qui appartient à cette session. Avant que l'AVP Identifiant de session alloué soit reçue d'un homologue, les messages DOIVENT être envoyés à cet homologue avec un identifiant de session de 0 dans l'en-tête de tous les messages de commande.
Dans le message de commande CDN, on utilise la même AVP Identifiant de session alloué qui a d'abord été envoyée à l'homologue qui reçoit, ce qui lui permet d'identifier le tunnel approprié même si CDN est envoyé avant qu'un Identifiant de session alloué ne soit reçu.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 8.
Numéro de série de l'appel (ICRQ, OCRQ)
L'AVP Numéro de série de l'appel, type d'attribut 15, code un identifiant alloué par le LAC ou le LNS à cet appel.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro de série de l'appel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Numéro de série de l'appel est une valeur de 32 bits.
Le Numéro de série de l'appel est destiné à être une référence commode pour les administrateurs aux deux extrémités du tunnel, à utiliser pour faire des recherches sur les problèmes d'échec d'un appel. Les numéros de série d'appel devraient être mis à des valeurs progressivement croissantes, qui seront vraisemblablement uniques pour une période significative à travers tous les LNS et LAC interconnectés.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
BPS minimum (OCRQ)
L'AVP BPS minimum, type d'attribut 16, code la plus faible vitesse de ligne acceptable pour cet appel.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS minimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS minimum est une valeur de 32 bits qui indique la vitesse en bits par seconde.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
BPS maximum (OCRQ)
L'AVP BPS maximum, type d'attribut 17, code la plus haute vitesse de ligne acceptable pour cet appel.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS maximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS maximum est une valeur de 32 bits qui indique la vitesse en bits par seconde.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
Type de support (ICRQ, OCRQ)
L'AVP Type de support, type d'attribut 18, code le type de support pour un appel entrant ou sortant.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé pour les types de support futurs |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type de support est un gabarit binaire de 32 bits, qui indique la capacité de support de l'appel (ICRQ) ou demandée pour l'appel (OCRQ). Si il est mis, le bit A indique que l'appel se réfère à un canal analogique. Si il est mis, le bit D indique que l'appel se réfère à un canal numérique. Tous deux peuvent être établis, ce qui indique que l'appel était soit non distinguable, soit peut être passé sur l'un et l'autre type de canal.
Les bits dans le champ Valeur de cette AVP DOIVENT seulement être établis par le LNS pour une OCRQ si il était mis dans l'AVP Capacités support reçue du LAC durant l'établissement de la connexion de contrôle.
Il est valide de n'établir ni le bit A ni le bit D dans une ICRQ. Un tel réglage peut indiquer que l'appel n'a pas été reçu sur une liaison physique (par exemple si le LAC et PPP sont situés dans le même sous-système).
Cette AVP peur être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
Type de tramage (ICCN, OCCN, OCRQ)
L'AVP Type de tramage, type d'attribut 19, code le type de tramage pour l'appel entrant ou sortant.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé pour les types de tramage futurs |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type de tramage est un gabarit de 32 bits, qui indique le type de tramage PPP demandé pour une OCRQ, ou le type de tramage PPP négocié pour une OCCN ou une ICCN. Le type de tramage PEUT être utilisé comme indication à PPP sur le LNS et les options de liaisons à utiliser pour la négociation de LCP [RFC1662].
Le bit A indique un tramage asynchrone. Le bit S indique un tramage synchrone. Pour une OCRQ, les deux peuvent être mis, indiquant que l'un ou l'autre type de tramage peut être utilisé.
Les bits du champ Valeur de cette AVP DOIVENT seulement être mis par le LNS pour une OCRQ si ils étaient mis dans l'AVP Capacités de tramage reçue du LAC durant l'établissement de la connexion de contrôle.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
Numéro demandé (ICRQ, OCRQ)
L'AVP Numéro demandé, type d'attribut 21, code le numéro de téléphone à appeler pour une OCRQ, et le numéro demandé pour une ICRQ.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro demandé.. (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Numéro demandé est une chaîne ASCII. Un contact entre l'administrateur du LAC et du LNS peut être nécessaire pour coordonner l'interprétation de la valeur nécessaire dans cette AVP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur du numéro demandé.
Numéro appelant (ICRQ)
L'AVP Numéro appelant, type d'attribut 22, code le numéro d'origine de l'appel entrant.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro appelant ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Numéro appelant est une chaîne ASCII. Un contact entre l'administrateur du LAC et du LNS peut être nécessaire pour coordonner l'interprétation de la valeur nécessaire dans cette AVP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur du numéro appelant.
Sous-adresse (ICRQ, OCRQ)
L'AVP Sous-adresse, type d'attribut 23, code des informations supplémentaires de numérotage.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sous-adresse ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sous-adresse est une chaîne ASCII. Un contact entre l'administrateur du LAC et du LNS peut être nécessaire pour coordonner l'interprétation de la valeur nécessaire dans cette AVP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de la sous-adresse.
Vitesse de connexion (Tx) (ICCN, OCCN)
L'AVP Vitesse de connexion (Tx) BPS, type d'attribut 24, code la vitesse de la facilité choisie pour la tentative de connexion.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vitesse de connexion (Tx) BPS est une valeur de 4 octet qui indique la vitesse en bits par seconde.
Lorsque l'AVP facultative Vitesse de connexion Rx est présente, la valeur de cette AVP représente la vitesse d'émission de la connexion, du point de vue du LAC (par exemple, du flux de données du LAC au système distant). Lorsque l'AVP facultative Vitesse de connexion Rx N'EST PAS présente, la vitesse de connexion entre le système distant et le LAC est supposée être symétrique et est représentée par la seule valeur de cette AVP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 10.
Vitesse de connexion Rx (ICCN, OCCN)
L'AVP Vitesse de connexion Rx, type d'attribut 38, représente la vitesse de la connexion du point de vue du LAC (par exemple du flux de données du système distant au LAC).
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS est une valeur de 4 octets qui indique la vitesse en bits par seconde.
La présence de cette AVP implique que la vitesse de la connexion peut être asymétrique par rapport à la vitesse d'émission de la connexion donnée dans l'AVP Vitesse de connexion (Tx).
Cette AVP peut être cachée (le bit H PEUT être 1 ou 0). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 10.
Identifiant de canal physique (ICRQ, OCRP)
L'AVP Identifiant de canal physique, type d'attribut 25, code le numéro de canal physique spécifique du fabricant utilisé pour un appel.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de canal physique |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de canal physique est une valeur de 4 octets destinée à être seulement utilisée pour les besoins de connexion.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 10.
Identifiant de groupe privé (ICCN)
L'AVP Identifiant de groupe privé, type d'attribut 37, est utilisée par le LAC pour indiquer que cet appel est à associer à un groupe particulier de consommateurs.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de groupe privé ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de groupe privé est une chaîne d'octets de longueur arbitraire.
Le LNS PEUT traiter la session PPP aussi bien que le trafic réseau à travers cette session d'une façon particulière déterminée par l'homologue. Par exemple, si le LNS est connecté individuellement à plusieurs réseaux privés en utilisant des adresses non enregistrées, cette AVP peut être incluse par le LAC pour indiquer qu'un appel donné devrait être associé à un des réseaux privés.
Identifiant de groupe privé est une chaîne correspondant à un tableau dans le LNS qui définit les caractéristiques particulières du groupe choisi. Un LAC PEUT déterminer l'identifiant de groupe privé à partir d'une réponse RADIUS, de la configuration locale, ou de quelque autre source.
Cette AVP peut être cachée (le bit H PEUT être 1 ou 0). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de l'identifiant de groupe privé.
Séquencement exigé (ICCN, OCCN)
L'AVP Séquencement exigé, type d'attribut 39, indique au LNS que les numéros de séquence DOIVENT toujours être présents sur le canal de données.
Cette AVP n'a pas de champ Valeur d'attribut.
Cette AVP NE DOIT PAS être cachée (le bit H DOIT être 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 6.
Le LAC peut avoir répondu à l'appel et négocié LCP avec le système distant, peut-être afin d'établir l'identité apparente du système. Dans ce cas, ces AVP peuvent être incluses pour indiquer les propriétés que le système distant demandait initialement aux liaisons, propriétés que le système distant et le LAC ont ensuite négocié, ainsi que les informations d'authentification PPP envoyées et reçues par le LAC. Ces informations peuvent être utilisées pour initier le LCP PPP et les systèmes d'authentification sur le LNS, permettant à PPP de continuer sans renégociation de LCP. Noter que la politique de LNS peut être d'entrer dans un tour supplémentaire de négociation de LCP et/ou d'authentification si le LAC n'est pas de confiance.
CONFREQ LCP reçue initiale (ICCN)
L'AVP CONFREQ LCP reçue initiale, type d'attribut 26, donne au LNS la CONFREQ initiale reçue par le LAC de l'homologue PPP.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONFREQ LCP ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONFREQ LCP est une copie du corps de la CONFREQ initiale reçue, commençant à la première option au sein du corps du message LCP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de la CONFREQ.
CONFREQ LCP dernière envoyée (ICCN)
L'AVP CONFREQ LCP dernière envoyée, type d'attribut 27, donne au LNS la dernière CONFREQ envoyée par le LAC à l'homologue PPP.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONFREQ LCP ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONFREQ LCP est une copie du corps de la CONFREQ finale envoyée au client pour achever la négociation de LCP, en commençant par la première option au sein du corps du message LCP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de la CONFREQ.
CONFREQ LCP dernière reçue (ICCN)
L'AVP CONFREQ LCP dernière reçue, type d'attribut 28, donne au LNS la dernière CONFREQ LCP reçue par le LAC de l'homologue PPP.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONFREQ LCP ... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONFREQ LCP est une copie du corps de la CONFREQ finale reçue du client pour terminer la négociation de LCP, en commençant à la première option au sein du corps du message LCP.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de la CONFREQ.
Type d'authentification de mandataire (ICCN)
L'AVP Type d'authentification de mandataire, type d'attribut 29, détermine si l'authentification du mandataire devrait être utilisée.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type d'authentification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type d'authentification est un entier non signé de deux octets.
Cette AVP peur être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 8.
Les valeurs définies de type d'authentification sont :
0 - Réservé
1 – Échange de nom d'utilisateur/mot de passe textuel
2 – CHAP PPP
3 – PAP PPP
4 – Pas d'authentification
5 – CHAP Microsoft version 1 (MSCHAPv1)
Cette AVP DOIT être présente si l'authentification de mandataire doit être utilisée. Si elle n'est pas présente, on suppose alors que cet homologue ne peut pas effectuer l'authentification du mandataire, ce qui exige un redémarrage de la phase d'authentification au LNS si le client est déjà entré dans cette phase avec le LAC (ce qui peut être déterminé par l'AVP LCP de mandataire, si elle est présente).
Les AVP associées pour chaque type d'authentification figurent ci-après.
Nom d'authentification de mandataire (ICCN)
L'AVP Nom d'authentification de mandataire, type d'attribut 30, spécifie le nom du client qui authentifie lorsque on utilise l'authentification du mandataire.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nom d'authentification... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nom d'authentification est une chaîne d'octets de longueur arbitraire. Il contient le nom spécifié dans la réponse d'authentification du client.
Cette AVP DOIT être présente dans les messages qui contiennent une AVP Type d'authentification du mandataire avec un type d'authentification de 1, 2, 3 ou 5. Il peut être souhaitable d'employer la dissimulation d'AVP pour le texte en clair du nom.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) est 6 plus la longueur du texte en clair du nom.
Challenge d'authentification du mandataire (ICCN)
L'AVP Challenge d'authentification du mandataire, type d'attribut 31, spécifie le challenge envoyé par le LAC à l'homologue PPP, lors de l'utilisation de l'authentification du mandataire.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Challenge est une chaîne d'un ou plusieurs octets.
Cette AVP DOIT être présente pour les types d'authentification de mandataire 2 et 5. Le champ Challenge contient le challenge CHAP présenté au client par le LAC.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6, plus la longueur du challenge.
Identifiant d'authentification de mandataire (ICCN)
L'AVP Identifiant d'authentification de mandataire, type d'attribut 32, spécifie la valeur de l'identifiant de l'authentification PPP qui a été commencée entre le LAC et l'homologue PPP, lorsque l'authentification du mandataire est utilisée.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID est un entier non signé de deux octets, l'octet de poids fort DOIT être 0.
L'AVP Identifiant d'authentification de mandataire DOIT être présente pour les types d'authentification de mandataire 2, 3 et 5. Pour 2 et 5, le champ ID contient la valeur de l'octet ID présentée au client par le LAC dans son challenge. Pour 3, c'est la valeur de l'identifiant de la demande d'authentification.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0.
Réponse d'authentification de mandataire (ICCN)
L'AVP Réponse d'authentification de mandataire, type d'attribut 33, spécifie la réponse d'authentification PPP reçue par le LAC de l'homologue PPP, lorsque l'authentification de mandataire est utilisée.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réponse... (nombre arbitraire d'octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Réponse est une chaîne d'octets.
Cette AVP DOIT être présente pour les types d'authentification de mandataire 1, 2, 3 et 5. Le champ Réponse contient la réponse su client au challenge. Pour les types d'authentification de mandataire 2 et 5, ce champ contient la valeur de réponse reçue par le LAC. Pour les types 1 ou 3, il contient le mot de passe en clair reçu du client par le LAC. Dans le cas de mots de passe en clair, la dissimulation de l'AVP est recommandée.
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur (avant dissimulation) de cette AVP est 6 plus la longueur de la réponse.
Erreurs d'appel (WEN)
L'AVP Erreurs d'appel, type d'attribut 34, est utilisée par le LAC pour envoyer des informations d'erreur au LNS.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé | Erreurs de CRC (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Erreurs de CRC (L) | Erreurs de tramage (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Erreurs de tramage (L) | Dépassements matériels (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dépassements matériels (L) | Dépassement mémoire tampon (H)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dépassement mémoire tampon (L)| Fin de temporisation (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fin de temporisation (L) | Erreur de verrouillage (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Erreur de verrouillage (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les champs suivants sont définis :
Réservé – Non utilisé, DOIT être à 0
Erreurs de CRC - Nombre de trames PPP reçues avec des erreurs de CRC depuis l'établissement de l'appel
Erreurs de tramage - Nombre de paquets PPP reçus avec un tramage impropre
Dépassement de matériel - Nombre de débordements de mémoire tampon de réception depuis l'établissement de l'appel
Dépassements de mémoire tampon - Nombre de dépassements de mémoire tampon détectés depuis l'établissement de l'appel
Erreurs de temporisation - Nombre de fins de temporisation atteintes depuis l'établissement de l'appel
Erreurs de verrouillage - Nombre d'erreurs de verrouillage de trame depuis l'établissement de l'appel
Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 1. La longueur (avant dissimulation) de cette AVP est 32.
ACCM (SLI)
L'AVP ACCM, type d'attribut 35, est utilisée par le LNS pour informer le LAC de l'ACCM négociée avec l'homologue PPP par le LNS.
Le champ Valeur d'attribut pour cette AVP a le format suivant :
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé | ACCM envoyée (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACCM envoyée (L) | ACCM reçue (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACCM reçue (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACCM envoyée et ACCM reçue sont chacune des valeurs de 4 octets précédées par une quantité réservée de 2 octets. La valeur de l'ACCM envoyée devrait être utilisée par le LAC pour traiter les paquets qu'il envoie sur la connexion. La valeur de l'ACCM reçue devrait être utilisée par le LAC pour traiter les paquets entrants sur la connexion. Les valeurs par défaut utilisées par le LAC pour ces deux champs sont 0xFFFFFFFF. Le LAC devrait respecter ces champs sauf si il a des informations spécifiques de la configuration pour indique que le gabarit demandé doit être modifié pour permettre le fonctionnement.
Cette AVP peut être cachée (le bit H PEUT être 1 ou 0). Le bit M pour cette AVP DOIT être mis à 1. La longueur de cette AVP est 16.
5. Fonctionnement du protocole
Le réglage nécessaire pour tunneler une session PPP avec L2TP comporte deux étapes, (1) établir la connexion de contrôle pour un tunnel, et (2) établir une session comme déclanchée par une demande d'appel entrant ou sortant. Le tunnel et la connexion de contrôle correspondante DOIVENT être établis avant que soit initié un appel entrant ou sortant. Une session L2TP DOIT être établie avant que L2TP puisse commencer à tunneler des trames PPP. Plusieurs sessions peuvent exister à travers un seul tunnel et plusieurs tunnels peuvent exister entre le même LAC et LNS.
+-----+ +-----+
| |~~~~~~~~~~Tunnel L2TP~~~~~~~~~~| |
| LAC | | LNS |
| #######Connexion de contrôle######## |
[Système] | | | |
[distant]-----Appel---------*============ Session L2TP=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Système] | | | |
[distant]-----Appel---------*============Session L2TP=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
Figure 5.1 : Tunnelage PPP
5.1 Établissement d'une connexion de contrôle
La connexion de contrôle est la connexion initiale qui doit être établie entre le LAC et le LNS avant que les sessions puissent exister. L'établissement de la connexion de contrôle comporte de s'assurer de l'identité de l'homologue, ainsi que d'identifier la version L2TP, le tramage et les capacités support, etc. de celui-ci.
Un échange de trois messages est utilisé pour établir la connexion de contrôle. Voici un échange de message normal :
LAC ou LNS |
LAC ou LNS |
SCCRQ ---> |
|
|
<--- SCCRP |
SCCCN ---> |
|
|
<--- ACK ZLB |
Le ACK ZLB est envoyé si il n'y a pas d'autres messages qui sont dans la file d'attente pour cet homologue.
L2TP comporte un système d'authentification de tunnel simple, facultatif, de style CHAP [RFC1994] durant l'établissement de la connexion de contrôle. Si un LAC ou LNS souhaite authentifier l'identité de l'homologue qu'il contacte ou qui le contacte, une AVP Challenge est incluse dans le message SCCRQ ou SCCRP. Si une AVP Challenge est reçue dans une SCCRQ ou SCCRP, une AVP Réponse de challenge DOIT être envoyée respectivement dans le SCCRP ou SCCCN suivant. Si la réponse attendue et la réponse reçue d'un homologue ne correspondent pas, l'établissement du tunnel DOIT être interdit.
Pour participer à l'authentification du tunnel, un seul secret partagé DOIT exister entre le LAC et le LNS. C'est le même secret partagé que celui utilisé pour dissimuler une AVP (voir au paragraphe 4.3). Voir au paragraphe 4.4.3 les détails sur la construction des AVP Challenge et Réponse de challenge.
Après la réussite de l'établissement de la connexion de contrôle, des sessions individuelles peuvent être créées. Chaque session correspond à un seul flux PPP entre le LAC et le LNS. À la différence de l'établissement de la connexion de contrôle, l'établissement de session est directionnel par rapport au LAC et au LNS. Le LAC demande au LNS d'accepter une session pour un appel entrant, et le LNS demande au LAC d'accepter une session pour placer un appel sortant.
Un échange de trois messages est employé pour établir la session. Voici une séquence d'événements normale :
LAC |
LNS |
(appel détecté) ICRQ -----> |
|
|
<---ICRP |
ICCN -----> |
|
|
<--- ACK ZLB |
Le ACK ZLB est envoyé si il n'y a pas d'autre message dans la file d'attente pour cet homologue.
Un échange de trois messages est employé pour établir la session. Voici une séquence d'événements normale :
LAC |
LNS |
|
<------OCRQ |
OCRP --------------> |
|
(effectuer l'opération d'appel) |
|
OCCN -------------> |
|
|
<------ ACK ZLB |
Le ACK ZLB est envoyé si il n'y a pas d'autre message dans la file d'attente pour cet homologue.
5.3 Transmission des trames PPP
Une fois achevé l'établissement du tunnel, les trames PPP provenant du système distant sont reçue au LAC, débarrassées du CRC, du tramage de liaison, et des octets de transparence, encapsulées dans L2TP, et transmises sur le tunnel approprié. Le LNS reçoit le paquet L2TP, et traite la trame PPP encapsulée comme si elles étaient reçues sur une interface PPP locale.
L'envoyeur d'un message associé à une session et tunnel particuliers place les identifiants de session et de tunnel (spécifiés par son homologue) dans l'en-tête Identifiant de session et Identifiant de tunnel pour tous les messages sortants. De cette manière, les trames PPP sont multiplexées et démultiplexées sur un seul tunnel entre une paire LNS-LAC donnée. Plusieurs tunnels peuvent exister entre une paire LNS-LAC donnée, et plusieurs sessions peuvent exister au sein d'un tunnel.
La valeur 0 pour l'identifiant de session et l'identifiant de tunnel est particulière et NE DOIT PAS être utilisée comme identifiant de session ou identifiant de tunnel alloués. Pour les cas où un identifiant de session n'a pas encore été alloué par l'homologue (c'est-à-dire, durant l'établissement d'une nouvelle session ou d'un nouveau tunnel) le champ Identifiant de session DOIT être envoyé à 0, et l'AVP Identifiant de session alloué au sein du message DOIT être utilisé pour identifier la session. De même, pour les cas où l'identifiant de tunnel n'a pas encore été alloué par l'homologue, l'identifiant de tunnel DOIT être envoyé à 0 et l'AVP Identifiant de tunnel alloué utilisé pour identifier le tunnel.
5.4 Utilisation des numéros de séquence sur le canal de données
Les numéros de séquence sont définis dans l'en-tête L2TP pour les messages de commande et facultativement pour les messages de données (voir au paragraphe 3.1). Il sont utilisés pour fournir un transport fiable de message de commande (voir au paragraphe 5.8) et un séquencement facultatif des messages de données. Chaque homologue entretient des numéros de séquence distincts pour la connexion de contrôle et chaque session de données individuelle au sein d'un tunnel.
À la différence du canal de commande L2TP, le canal de données L2TP n'utilise pas les numéros de séquence pour retransmettre les messages de données perdus. Les messages de données peuvent plutôt utiliser des numéros de séquence pour détecter les paquets perdus et/ou restaurer la séquence d'origine des paquets qui peuvent avoir été réarrangés durant le transport. Le LAC peut demander que les numéros de séquence soient présents dans les messages de données via l'AVP Séquencement exigé (voir au paragraphe 4.4.4). Si cette AVP est présente durant l'établissement de session, les numéros de séquence DOIVENT être présents à chaque fois. Si cette AVP n'est pas présente, la présence du séquencement est de la responsabilité du LNS. Le LNS commande l'activation et la désactivation des numéros de séquence en envoyant un message de données avec ou sans les numéros de séquence présents à tout moment durant la vie d'une session. Et donc, si le LAC reçoit un message de données sans que les numéros de séquence soient présents, il DOIT arrêter d'envoyer des numéros de séquence dans les messages de données ultérieurs. Si le LAC reçoit un message de données avec les numéros de séquence, il DOIT commencer d'envoyer des numéros de séquence dans les messages de données sortants ultérieurs. Si le LNS active le séquençage après l'avoir désactiver plus tôt dans la session, le numéro de séquence reprend où il s'était arrêté précédemment.
Le LNS peut initier la désactivation du séquençage à tout moment durant la session (y compris au premier message de données envoyé). Il est recommandé que pour les connexions où peut survenir le réarrangement ou la perte de paquet, les numéros de séquence soient toujours activés durant les phases de négociation initiale de PPP et ne soient désactivées que lorsque et si le risque est considéré comme acceptable. Par exemple, si la session PPP qui va être tunnelée n'utilise aucun protocole de compression à états pleins ou de chiffrement et ne porte que IP (comme déterminé par les NCP PPP qui sont établis) le LNS peut alors décider de désactiver le séquencement car IP est tolérant aux datagrammes perdus et réarrangés.
Un mécanisme de maintien en vie est employé par L2TP afin de différencier les pannes de tunnel des longues périodes de non contrôle ou activité de données sur un tunnel. Cela se fait en injectant des messages de commande Hello (voir au paragraphe 6.5) après l'écoulement d'une période de temps spécifiée depuis la réception du dernier message de données ou de commande sur un tunnel. Comme pour tout autre message de commande, si le message Hello n'est pas livré de façon fiable le tunnel est alors déclaré défaillant et est rétabli. Le mécanisme de rétablissement du transport ainsi que l'injection des messages Hello assure qu'une défaillance de connexité entre le LNS et le LAC sera détectée aux deux extrémités d'un tunnel.
La suppression de session peut être initiée par l'un ou l'autre du LAC ou du LNS et elle est réalisée par l'envoi d'un message de commande CDN. Après la libération de la dernière session, la connexion de contrôle PEUT être supprimée aussi (et l'est normalement). Un exemple d'échange normal de messages de commande figure ci-après :
LAC ou LNS |
LAC ou LNS |
CDN -> (Nettoyage) |
|
|
<- ACK ZLB (Nettoyage) |
5.7 Suppression de connexion de contrôle
La suppression de connexion de contrôle peut être initiée par le LAC ou le LNS et elle est réalisée par l'envoi d'un seul message de commande StopCCN. Celui qui reçoit un StopCCN DOIT envoyer un ACK ZLB pour accuser réception du message et conserver assez d'état de connexion de contrôle pour accepter correctement les retransmissions de StopCCN sur au moins un cycle complet de retransmission (au cas où le ACK ZLB serait perdu). La durée recommandée pour une cycle de retransmission complet est 31 secondes (voir au paragraphe 5.8). Un exemple d'échange normal de messages de commande figure ci-après :
LAC ou LNS |
LAC ou LNS |
StopCCN -> (Nettoyage) |
|
|
<- ACK ZLB (Attente) (Nettoyage) |
Une mise en œuvre peut clore un tunnel entier et toutes les sessions sur le tunnel en envoyant le StopCCN. Et donc, il n'est pas nécessaire de clore chaque session individuellement lorsque on supprime le tunnel tout entier.
5.8 Livraison fiable des messages de commande
L2TP fournit un service de transport fiable de niveau inférieur pour tous les messages de commande. Les champs Nr et Ns de l'en-tête de message de commande (voir au paragraphe 3.1) appartiennent à ce transport. Les fonctions de niveau supérieur de L2TP ne sont pas concernées par la retransmission ou le réarrangement des messages de commande. Le message de commande fiable est un transport de fenêtre glissante qui assure la retransmission et le contrôle d'encombrement des messages de commande. Chaque homologue entretient un état de numéro de séquence séparé pour la connexion de contrôle au sein d'un tunnel.
Le numéro de séquence du message, Ns, commence à 0. Chaque message suivant est envoyé avec l'incrément suivant de numéro de séquence. Le numéro de séquence est donc un compteur en fonctionnement libre qui est représenté modulo 65536. Le numéro de séquence dans l'en-tête d'un message reçu est considéré inférieur ou égal au dernier numéro reçu si sa valeur se tient dans la gamme du dernier numéro reçu et des 32767 valeurs précédentes, incluses. Par exemple, si le dernier numéro de séquence reçu était 15, les messages avec les numéros de séquence de 0 à 15, ainsi que de 32784 à 65535, seront considérés comme inférieurs ou égaux. Un tel message serait considéré comme un duplicata d'un message déjà reçu et ignoré pour le traitement. Cependant, afin de s'assurer que tous les messages ont été acquittés correctement (en particulier dans le cas d'un message ACK ZLB perdu) la réception de messages dupliqués DOIT recevoir un accusé de réception du transport fiable. Cet accusé de réception peut soit être porté sur un message en file d'attente, soit être explicite via un ACK ZLB.
Tous les messages de commande prennent un intervalle dans l'espace de numéro de séquence de message de commande, sauf l'accusé de réception ZLB. Et donc, Ns n'est pas incrémenté après l'envoi d'un message ZLB.
Le dernier numéro de message reçu, Nr, est utilisé pour accuser réception des messages reçus par un homologue L2TP. Il contient le numéro de séquence du message que l'homologue s'attend à recevoir ensuite (par exemple le dernier Ns d'un message non ZLB reçu plus 1, modulo 65536). Alors que Nr dans un ZLB reçu est utilisé pour purger les messages de la file d'attente de retransmission locale (voir ci-dessous) le Nr du prochain message envoyé n'est pas mis à jour par le Ns du ZLB.
Le transport fiable est chargé chez l'homologue receveur de s'assurer que les messages de commande sont livrés dans l'ordre et sans duplication au niveau supérieur. Les messages qui arrivent en désordre peuvent être mis en file d'attente pour une livraison dans l'ordre lorsque les messages manquants sont reçus, ou ils peuvent être éliminés en exigeant la retransmission par l'homologue.
Chaque tunnel entretient une file d'attente de messages de commande à transmettre à son homologue. Le message en tête de la file d'attente est envoyé avec une valeur Ns donnée, et il est conservé jusque à ce que un message de commande arrive de l'homologue dans lequel le champ Nr indique la réception de ce message. Après une période de temps (la valeur recommandée par défaut est une seconde) passée sans accusé de réception, le message est retransmis. Le message retransmis contient la même valeur Ns, mais la valeur de Nr DOIT être mise à jour avec le numéro de séquence du prochain message attendu.
Chaque retransmission suivante d'un message DOIT employer un intervalle de retard exponentiel. Et donc, si la première retransmission survient après une seconde, la prochaine retransmission devrait intervenir après deux secondes, puis quatre secondes, etc. Une mise en œuvre PEUT fixer un intervalle maximum entre les retransmissions. Ce maximum NE DOIT PAS être inférieur à huit secondes par retransmission. Si aucune réponse de l'homologue n'est détectée après plusieurs retransmissions, (la valeur recommandée par défaut est 5, mais DEVRAIT être configurable) le tunnel et toutes les sessions qui sont dedans DOIVENT être libérés.
Lorsque un tunnel est fermé pour des raisons autres que la perte de connexité, l'état et les mécanismes de livraison fiable DOIVENT être maintenus et fonctionner sur l'intervalle de retransmission complet après que soit intervenu l'échange final de messages.
Un mécanisme de fenêtre glissante est utilisé pour la transmission des messages de commande. Considérons deux homologues A & B. Supposons que A spécifie une AVP Taille de fenêtre de réception d'une valeur de N dans les messages SCCRQ ou SCCRP. B est maintenant autorisé à avoir jusqu'à N messages de commande en instance. Une fois que N a été envoyé, il doit attendre un accusé de réception qui avance la fenêtre avant d'envoyer de nouveaux messages de commande. Une mise en œuvre peut accepter une fenêtre de réception de seulement 1 (c'est-à-dire, en envoyant une AVP Taille de fenêtre de réception d'une valeur de 1) mais DOIT accepter une fenêtre jusqu'à 4 de son homologue (par exemple avoir la capacité d'envoyer 4 messages avant le repli). Une valeur de 0 pour l'AVP Taille de fenêtre de réception est invalide.
Lors de la retransmission de messages de commande, on DEVRAIT utiliser une procédure d'ajustement de fenêtre de démarrage lent et d'évitement d'encombrement. La procédure recommandée pour cela est décrite dans l'Appendice A.
Un homologue NE DOIT PAS retenir les accusés de réception des messages comme technique de contrôle des flux de messages de commande. Une mise en œuvre de L2TP est censée être capable de garder le contrôle des messages de commande entrants, éventuellement en répondant à certains avec des erreurs reflétant l'incapacité à honorer l'action demandée.
L'Appendice B contient des exemples de transmission, d'accusés de réception et de retransmission de messages de commande.
6. Spécification du protocole de connexion de contrôle
Les message de connexion de contrôle suivants sont utilisés pour établir supprimer et entretenir les tunnels L2TP. Toutes les données sont envoyées dans l'ordre du réseau (octets de poids fort en premier). Tous les champs "réservé" ou "vide" DOIVENT être envoyés à 0 pour permettre l'extension future du protocole.
6.1 Demande de début de connexion de contrôle (SCCRQ)
Demande de début de connexion de contrôle (SCCRQ, Start-Control-Connection-Request) est un message de commande utilisé pour initialiser un tunnel entre un LNS et un LAC. Il est envoyé soit par le LAC soit par le LNS qui va être le processus d'établissement du tunnel.
Les AVP suivantes DOIVENT être présentes dans la SCCRQ :
Type de message
Version du protocole
Nom d'hôte
Capacités de tramage
Identifiant de tunnel alloué
Les AVP suivantes PEUVENT être présentes dans la SCCRQ :
Capacités de support
Taille de fenêtre de réception
Challenge
Départage
Révision de microcode
Nom du fabricant
6.2 Réponse de début de connexion de contrôle (SCCRP)
Réponse de début de connexion de contrôle (SCCRP, Start-Control-Connection-Reply) est un message de commande envoyé en réponse à un message SCCRQ reçu. SCCRP est utilisé pour indiquer que le SCCRQ a été accepté et que l'établissement du tunnel devrait se poursuivre.
Les AVP suivantes DOIVENT être présentes dans la SCCRP :
Type de message
Version du protocole
Capacités de tramage
Nom d'hôte
Identifiant de tunnel alloué
Les AVP suivantes PEUVENT être présentes dans la SCCRP :
Capacités de support
Révision de microcode
Nom du fabricant
Taille de fenêtre de réception
Challenge
Réponse au challenge
6.3 Début de connexion de contrôle connecté (SCCCN)
Début de connexion de contrôle connecté (SCCCN, Start-Control-Connection-Connected) est un message de commande envoyé en réponse à une SCCRP. SCCCN achève le processus d'établissement du tunnel.
Les AVP suivantes DOIVENT être présentes dans la SCCCN :
Type de message
Les AVP suivantes PEUVENT être présentes dans la SCCCN :
Réponse au challenge
6.4 Notification d'arrêt de connexion de contrôle (StopCCN)
Notification d'arrêt de connexion de contrôle (StopCCN, Stop-Control-Connection-Notification) est un message de commande envoyé par le LAC ou le LNS pour informer son homologue de la clôture imminente du tunnel et de ce que la connexion de contrôle devrait être fermée. De plus, toutes les sessions actives sont implicitement libérées (sans envoi d'aucun message explicite de commande d'appel). La raison de la production de cette demande est indiquée dans l'AVP Code de résultat. Il n'y a pas de réponse explicite à ce message, seulement le ACK implicite qui est reçu par la couche de transport fiable de message de commande.
Les AVP suivantes DOIVENT être présentes dans la StopCCN :
Type de message
Identifiant de tunnel alloué
Code de résultat
Le message d'accueil (HELLO) est un message de commande L2TP envoyé par l'un et l'autre homologues d'une connexion de contrôle LAC-LNS. Ce message de commande est utilisé comme "maintien en vie" pour le tunnel.
L'envoi des messages HELLO et leur politique d'envoi est au gré de la mise en œuvre. Un homologue NE DOIT PAS attendre de messages HELLO à un délai ou intervalle donné. Comme avec tous les messages envoyés sur la connexion de contrôle, le receveur va retourner un ACK ZLB ou un message (sans rapport) qui porte les informations d'accusé de réception nécessaires.
Comme un HELLO est un message de commande, et que les messages de commande sont envoyés de façon fiable par le transport de niveau inférieur, cette fonction de maintien en vie fonctionne en causant la livraison fiable d'un message par le niveau transport. Si une interruption du support est intervenue, le transport fiable sera incapable de livrer le HELLO et va libérer le tunnel.
Les maintiens en vie pour les tunnels PEUVENT être mis en œuvre par l'envoi d'un HELLO si un délai s'est écoulé (valeur par défaut recommandée de 60 secondes, mais qui DEVRAIT être configurable) sans avoir reçu de message (données ou commande) de l'homologue.
Les messages HELLO sont globaux pour le tunnel. L'identifiant de session dans un message HELLO DOIT être 0.
L'AVP suivante DOIT être présente dans le message HELLO :
Type de message
6.6 Demande d'appel entrant (ICRQ)
Demande d'appel entrant (ICRQ, Incoming-Call-Request) est un message de commande envoyé par le LAC au LNS lorsque un appel entrant est détecté. C'est le premier message d'un échange de trois utilisé pour établir une session au sein d'un tunnel L2TP.
ICRQ est utilisée pour indiquer qu'une session va être établie entre le LAC et le LNS pour cet appel et fournit au LNS les informations de paramètres pour la session. Le LAC peut différer sa réponse à l'appel jusqu'à ce qu'il ait reçu une ICRP de la part du LNS indiquant que la session devrait être établie. Ce mécanisme permet au LNS d'obtenir des informations suffisantes sur l'appel avant de déterminer si il devrait ou non y répondre. Autrement, le LAC peut répondre à l'appel, négocier l'authentification de LCP et PPP, et utiliser les informations obtenues pour choisir le LNS. Dans ce cas, il a déjà été répondu à l'appel au moment où le message ICRP est reçu ; le LAC saute alors simplement les étapes "indication d'appel" et "réponse d'appel".
Les AVP suivantes DOIVENT être présentes dans la demande ICRQ :
Type de message
Identifiant de session alloué
Numéro de série de l'appel
Les AVP suivantes PEUVENT être présentes dans la demande ICRQ :
Type de support
Identifiant de canal physique
Numéro appelant
Numéro demandé
Sous-adresse
6.7 Réponse à appel entrant (ICRP)
Réponse à appel entrant (ICRP, Incoming-Call-Reply) est un message de commande envoyé par le LNS au LAC en réponse à un message ICRQ reçu. Il est le second dans l'échange de trois messages utilisé pour établir les sessions au sein d'un tunnel L2TP.
ICRP est utilisé pour indiquer que l'ICRQ a réussi et le LAC s'en sert pour répondre à l'appel si il ne l'a pas déjà fait. Il permet aussi au LNS d'indiquer les paramètres nécessaires pour la session L2TP.
Les AVP suivantes DOIT être présentes dans la réponse ICRP :
Type de message
Identifiant de session alloué
6.8 Appel entrant connecté (ICCN)
Appel entrant connecté (ICCN, Incoming-Call-Connected) est un message de commande envoyé par le LAC au LNS en réponse à un message ICRP reçu. Il est le troisième message de l'échange de trois utilisé pour établir les sessions au sein d'un tunnel L2TP.
ICCN est utilisé pour indiquer que l'ICRP a été acceptée, qu'il a été répondu à l'appel, et que la session L2TP devrait passer à l'état établi. Il fournit aussi des informations supplémentaires au LNS sur les paramètres utilisés pour l'appel auquel il est répondu (paramètres qui peuvent n'être pas toujours disponibles au moment de la production de la demande ICRQ).
Les AVP suivantes DOIT être présentes dans la demande ICCN :
Type de message
Vitesse de connexion (Tx)
Type de tramage
Les AVP suivantes PEUVENT être présentes dans la demande ICCN :
CONFREQ LCP initiale reçue
Dernière CONFREQ LCP envoyée
Dernière CONFREQ LCP reçue
Type d'authentification de mandataire
Nom d'authentification de mandataire
Challenge d'authentification de mandataire
Identifiant d'authentification de mandataire
Réponse d'authentification de mandataire
Identifiant de groupe privé
Vitesse de connexion Rx
Séquencement exigé
6.9 Demande d'appel sortant (OCRQ)
Demande d'appel sortant (OCRQ, Outgoing-Call-Request) est un message de commande envoyé par le LNS au LAC pour indiquer qu'un appel sortant provenant du LAC est à établir. C'est le premier d'un échange de trois messages utilisé pour établir une session au sein d'un tunnel L2TP.
OCRQ est utilisé pour indiquer qu'une session est à établir entre le LNS et le LAC pour cet appel et fournir au LAC les informations de paramètres à la fois pour la session L2TP et pour l'appel à passer.
Un LNS DOIT avoir reçu une AVP Capacités de support durant l'établissement du tunnel pour un LAC afin de demander un appel sortant avec ce LAC.
Les AVP suivantes DOIVENT être présentes dans la demande OCRQ :
Type de message
Identifiant de session alloué
Numéro de série de l'appel
BPS minimum
BPS maximum
Type de support
Type de tramage
Numéro demandé
L'AVP suivante PEUT être présente dans la demande OCRQ :
Sous-adresse
6.10 Réponse d'appel sortant (OCRP)
Réponse d'appel sortant (OCRP, Outgoing-Call-Reply) est un message de commande envoyé par le LAC au LNS en réponse à un message OCRQ reçu. C'est le second d'un échange de trois messages utilisé pour établir une session au sein d'un tunnel L2TP.
OCRP est utilisé pour indiquer que le LAC est capable de tenter l'appel sortant et retourner certains paramètres concernant la tentative d'appel.
Les AVP suivantes DOIVENT être présentes dans la réponse OCRP :
Type de message
Identifiant de session alloué
L'AVP suivante PEUT être présente dans la réponse OCRP :
Identifiant de canal physique
6.11 Appel sortant connecté (OCCN)
Appel sortant connecté (OCCN, Outgoing-Call-Connected) est un message de commande envoyé par le LAC au LNS suite à la réponse OCRP et après l'achèvement de l'appel sortant. Il est le message final de l'échange de trois messages utilisé pour établir une session au sein d'un tunnel L2TP.
OCCN est utilisé pour indiquer que le résultat d'une demande d'appel sortant est réussi. Il fournit aussi des informations au LNS sur les paramètres particuliers obtenus après l'établissement de l'appel.
Les AVP suivantes DOIVENT être présentes dans OCCN :
Type de message
Vitesse de connexion (Tx)
Type de tramage
Les AVP suivantes PEUVENT être présentes dans OCCN :
Vitesse de connexion Rx
Séquencement exigé
6.12 Notification d'appel déconnecté (CDN)
Le message Notification d'appel déconnecté (CDN, Call-Disconnect-Notify) est un message de commande L2TP envoyé par le LAC ou le LNS pour demander la déconnexion d'un appel spécifique au sein du tunnel. Son objet est d'informer l'homologue de la déconnexion et de la raison pour laquelle est intervenue la déconnexion. L'homologue DOIT libérer toutes les ressources, et ne renvoie aucune indication de réussite ou d'échec pour une telle libération.
Les AVP suivantes DOIVENT être présentes dans la CDN :
Type de message
Code de résultat
Identifiant de session alloué
L'AVP suivante PEUT être présente dans la CDN :
Code de cause Q.931
6.13 Notification d'erreur de (WEN)
Le message Notification d'erreur de WAN (WEN, WAN-Error-Notify) est un message de commande L2TP envoyé par le LAC au LNS pour indiquer les conditions d'erreur de WAN (conditions qui surviennent sur l'interface qui prend en charge PPP). Les compteurs dans ce message sont cumulatifs. Ce message ne devrait être envoyé que lorsque survient une erreur, et pas plus d'une fois toutes les 60 secondes. Les compteurs sont remis à zéro lorsque un nouvel appel est établi.
Les AVP suivantes DOIVENT être présentes dans la notification WEN :
Type de message
Erreurs d'appel
6.14 Informations d'établissement de liaison (SLI)
Le message Informations d'établissement de liaison (SLI, Set-Link-Info) est un message de commande L2TP envoyé par le LNS au LAC pour régler les options PPP négociées. Ces options peuvent changer à tout moment durant la vie de l'appel, et donc le LAC DOIT être capable de mettre à jour ses informations internes d'appel et son comportement sur une session PPP active.
Les AVP suivantes DOIVENT être présentes dans les SLI :
Type de message
ACCM
7. Automate à états de connexion de contrôle
Les messages de commande définis dans la section 6 sont échangés au moyen de tableaux d'état définis dans cette section. Les tableaux sont définis pour passer un appel entrant, un appel sortant, ainsi que pour l'initialisation du tunnel lui-même. Les tableaux d'état ne codent pas les comportements de fin de temporisation ni de retransmission, car ceux-ci sont traités dans la sémantique sous-jacente définie au paragraphe 5.8.
7.1 Fonctionnement du protocole de connexion de contrôle
Ce paragraphe décrit le fonctionnement de diverses fonctions L2TP de connexion de contrôle et les messages de connexion de contrôle qui sont utilisés pour les prendre en charge.
La réception d'un message de commande invalide ou mal formé irrécupérable devrait être enregistrée de façon appropriée et la connexion de contrôle libérée pour assurer la récupération à un état connu. La connexion de contrôle peut alors être redémarrée par l'initiateur.
Un message de commande invalide est défini comme un message qui contient un type de message marqué comme obligatoire (voir au paragraphe 4.4.1) et qui est inconnu de la mise en œuvre, ou un message de commande qui est reçu dans une séquence inappropriée (par exemple une SCCCN envoyée en réponse à une SCCRQ).
Les exemples de message de commande mal formés incluent celui qui a une valeur invalide dans son en-tête, qui contient une AVP qui est formatée de façon incorrecte ou dont la valeur est hors gamme, ou un message où il manque une AVP exigée. Un message de commande avec un en-tête mal formé devrait être éliminé. Un message de commande avec une AVP invalide devrait subir un examen du bit M de cette AVP pour déterminer si l'erreur est récupérable ou non.
Une AVP mal formée mais récupérable non obligatoire (bit M non établi) au sein d'un message de commande devrait être traitée de façon similaire comme une AVP non obligatoire non reconnue. Et donc, si une AVP mal formée est reçue avec le bit M non établi, la session ou tunnel devrait se terminer avec un code Résultat ou Erreur approprié. Si le bit M n'est pas mis, l'AVP devrait être ignorée (sauf à enregistrer un message d'erreur local) et le message accepté.
Cela NE DOIT PAS être considéré comme licence d'envoyer des AVP mal formées, mais simplement comme indication de la façon de traiter un message au formatage incorrect s'il en est reçu. Il est impossible de faire la liste de toutes les malformations possibles de message et de donner un avis pour chacune. Cela dit, un exemple d'AVP mal formée récupérable pourrait être celui d'une AVP Vitesse de connexion Rx, d'attribut 38, reçue avec une longueur de 8 plutôt que 10 et la BPS donnée en 2 octets plutôt qu'en 4. Comme Vitesse de connexion Rx est non obligatoire, cette condition ne devrait pas être considérée comme catastrophique. À ce titre, le message de commande devrait être accepté comme si l'AVP n'avait pas été reçue (sauf à enregistrer un message d'erreur local).
Dans plusieurs cas des tableaux suivants, un message du protocole est envoyé, puis survient un "nettoyage". Noter que sans considération de qui est l'initiateur de la destruction du tunnel, le mécanisme de livraison fiable doit être autorisé à fonctionner (voir au paragraphe 5.8) avant de détruire le tunnel. Cela permet que les messages de gestion du tunnel soient livrés de façon fiable à l'homologue.
L'Appendice B.1 contient un exemple d'établissement de tunnel verrouillé.
7.2 États de connexion de contrôle
Le protocole L2TP de connexion de contrôle ne se distingue pas vu du LNS et du LAC, mais il se distingue vu de l'origine et du receveur. L'homologue d'origine est celui qui le premier prend l'initiative de l'établissement du tunnel (dans une situation de départage, c'est le vainqueur du départage). Comme l'un et l'autre du LAC ou du LNS peut être l'origine, une collision peut survenir. Voir au paragraphe 4.4.3 la description de l'AVP Départage et sa résolution.
État |
Événement |
Action |
Nouvel état |
repos |
Demande d'ouverture locale |
Envoyer SCCRQ |
attente-réponse-ctl |
repos |
Reçoit SCCRQ, acceptable |
Envoyer SCCRP |
attente-connexion-ctl |
repos |
Reçoit SCCRQ, non acceptable |
Envoyer StopCCN, nettoyer |
repos |
repos |
Reçoit SCCRP |
Envoyer StopCCN, nettoyer |
repos |
repos |
Reçoit SCCCN |
nettoyer |
repos |
attente-réponse-ctl |
Reçoit SCCRP, acceptable |
Envoyer SCCCN, envoyer l'événement tunnel ouvert aux sessions en attente |
établi |
attente-réponse-ctl |
Reçoit SCCRP, non acceptable |
Envoyer StopCCN, nettoyer |
repos |
attente-réponse-ctl |
Reçoit SCCRQ, perd le départage |
Nettoyer, file d'attente SCCRQ pour l'état repos |
repos |
attente-réponse-ctl |
Reçoit SCCCN |
Envoyer StopCCN nettoyer |
repos |
attente-connexion-ctl |
Reçoit SCCCN, acceptable |
Envoyer l'événement tunnel ouvert aux sessions en attente |
établi |
attente-connexion-ctl |
Reçoit SCCCN, non acceptable |
Envoyer StopCCN, nettoyer |
repos |
attente-connexion-ctl |
Reçoit SCCRP, SCCRQ |
Envoyer StopCCN, nettoyer |
repos |
établi |
Demande d'ouverture locale (nouvel appel) |
Envoyer l'événement tunnel ouvert aux sessions en attente |
établi |
établi |
Fermeture administrative du tunnel |
Envoyer StopCCN, nettoyer |
repos |
établi |
Reçoit SCCRQ, SCCRP, SCCCN |
Envoyer StopCCN, nettoyer |
repos |
repos |
Reçoit StopCCN |
Nettoyer |
repos |
Les états associés au LNS ou au LAC pour l'établissement de la connexion de contrôle sont :
repos
L'initiateur et le receveur commencent tous deux de cet état. Un initiateur transmet une SCCRQ, alors qu'un receveur reste dans l'état repos jusqu'à ce qu'il reçoive une SCCRQ.
attente-réponse-ctl
L'origine vérifie pour voir si une autre connexion a été demandée chez le même homologue, et si il en est ainsi, traite la situation de collision décrite au paragraphe 5.8. Lorsque une SCCRP est reçue, elle est examinée à la recherche d'une version compatible. Si la version de la réponse est inférieure à la version envoyée dans la demande, la plus ancienne (la plus basse) version devrait être utilisée pourvu qu'elle soit prise en charge. Si la version dans la réponse est plus ancienne et prise en charge, l'origine passe à l'état établi. Si la version est plus ancienne et non prise en charge, un StopCCN DOIT être envoyé à l'homologue et l'origine nettoie et termine le tunnel.
attente-connexion-ctl
C'est là qu'on attend une SCCCN ; à réception, la réponse au challenge est vérifiée. Soit le tunnel est établi, soit il est supprimé si un échec d'autorisation est détecté.
établi
Une connexion établie peut se terminer par une condition locale ou par la réception d'une Notification d'arrêt de connexion de contrôle. Dans le cas d'une terminaison locale, l'origine DOIT envoyer une Notification d'arrêt de connexion de contrôle et libérer le tunnel.
Si l'origine reçoit une Notification d'arrêt de connexion de contrôle, elle DOIT aussi libérer le tunnel.
7.3 Considérations de temporisation
Du fait du caractère en temps réel de la signalisation téléphonique, le LNS et le LAC devraient tous deux mettre en œuvre une architecture multi chemins de sorte que les messages qui se rapportent à plusieurs appels ne soient pas mis en série et bloqués. Les valeurs d'état d'appel et de connexion ne spécifient pas les exceptions causées par les temporisateurs. Celles-ci sont traitées au paragraphe 5.8.
Un message Demande d'appel entrant est généré par le LAC lorsque un appel entrant est détecté (par exemple, une ligne téléphonique associée sonne). Le LAC choisit un identifiant de session et un numéro de série et indique le type de support de l'appel. Les modems devraient toujours indiquer le type d'appel analogique. Les appels RNIS devraient indiquer le numérique lorsque est utilisé un service numérique sans restriction ou d'adaptation de débit et l'analogique si des modems numériques sont impliqués. Le numéro appelant, le numéro demandé et la sous adresse peuvent être inclus dans le message si ils sont disponibles sur le réseau téléphonique.
Une fois que le LAC a envoyé la demande d'appel entrant, il attend une réponse de la part du LNS mais il ne répond pas nécessairement tout de suite à l'appel sur le réseau téléphonique. Le LNS peut choisir de ne pas accepter l'appel si :
- aucune ressource n'est disponible pour traiter d'autres sessions
- les champs numéroté, numérotant, ou de sous-adresse ne correspondent pas à un utilisateur autorisé
- le service support n'est pas autorisé ou accepté
Si le LNS choisit d'accepter l'appel, il répond par une Réponse d'appel entrant. Lorsque le LAC reçoit la Réponse d'appel entrant, il tente de connecter l'appel. Un message final appel connecté du LAC au LNS indique que les états d'appel du LAC et du LNS devraient entrer dans l'état établi. Si l'appel se termine avant que le LNS puisse l'accepter, une Notification d'appel déconnecté est envoyée au LAC pour indiquer cette condition.
Lorsque le client demandé raccroche, l'appel est libéré normalement et le LAC envoie un message Notification d'appel déconnecté. Si le LNS souhaite libérer un appel, il envoie un message Notification d'appel déconnecté et libère sa session.
État |
Événement |
Action |
Nouvel état |
repos |
Le support sonne ou prêt pour indiquer une connex. entrante |
Initie l'ouverture locale du tunnel |
attente-tunnel |
repos |
Reçoit ICCN, ICRP, CDN |
Nettoie |
repos |
attente-tunnel |
Abandon ligne support ou demande fermeture locale |
Nettoie |
repos |
attente-tunnel |
Tunnel ouvert |
Envoi d'ICRQ |
attente-réponse |
attente-réponse |
Reçoit ICRP, acceptable |
Envoi d'ICCN |
établi |
attente-réponse |
Reçoit ICRP, non acceptable |
Envoi de CDN, nettoie |
repos |
attente-réponse |
Reçoit ICRQ |
Envoi de CDN, nettoie |
repos |
attente-réponse |
Reçoit CDN, ICCN |
Nettoie |
repos |
attente-réponse |
Demande fermeture locale ou abandon ligne support |
Envoi de CDN, nettoie |
repos |
établi |
Reçoit CDN |
Nettoie |
repos |
établi |
Reçoit ICRQ, ICRP, ICCN |
Envoi de CDN, nettoie |
repos |
établi |
Abandon ligne support ou demande fermeture locale |
Envoi de CDN, nettoie |
repos |
Les états associés au LAC pour les appels entrants sont :
repos
Le LAC détecte un appel entrant sur une de ses interfaces. Cela veut normalement dire qu'une ligne analogique sonne ou qu'un terminal RNIS a détecté un message Établissement Q.931 entrant. Le LAC initie son automate à états d'établissement de tunnel, et passe à l'état d'attente de confirmation de l'existence d'un tunnel.
attente-tunnel
Dans cet état, la session attend l'ouverture de la connexion de contrôle ou la vérification de ce que le tunnel est déjà ouvert. Une fois qu'on a l'indication que le tunnel a été ouvert, les messages de commande de session peuvent être échangés. Le premier d'entre eux est la Demande d'appel entrant.
attente-réponse
Le LAC reçoit soit un message CDN qui indique que le LNS ne veut pas accepter l'appel (erreur générale ou n'accepte pas) et revient à l'état repos, soit un message Réponse d'appel entrant qui indique que l'appel est accepté, et le LAC envoie un message Appel entrant connecté et entre dans l'état établi.
établi
Des données sont échangées sur le tunnel. L'appel peut être libéré suite à :
+ un événement sur l'interface connectée : le LAC envoie un message Notification d'appel déconnecté
+ réception d'un message Notification d'appel déconnecté : le LAC nettoie, en déconnectant l'appel.
+ une cause locale : le LAC envoie un message Notification d'appel déconnecté.
État |
Événement |
Action |
Nouvel état |
repos |
Reçoit ICRQ, acceptable |
Envoie ICRP |
attente-connexion |
repos |
Reçoit ICRQ, non acceptable |
Envoie CDN, nettoie |
repos |
repos |
Reçoit ICRP |
Envoie CDN, nettoie |
repos |
repos |
Reçoit ICCN |
Nettoie |
repos |
attente-connexion |
Reçoit ICCN, acceptable |
Prepare for data |
établi |
attente-connexion |
Reçoit ICCN non acceptable |
Envoie CDN, nettoie |
repos |
attente-connexion |
Reçoit ICRQ, ICRP |
Envoie CDN, nettoie |
repos |
repos, attente-connexion, établi |
Reçoit CDN |
Nettoie |
repos |
attente-connexion établie |
Demande clôture locale |
Envoie CDN, nettoie |
repos |
établi |
Reçoit ICRQ, ICRP, ICCN |
Envoie CDN, nettoie |
repos |
Les états associés au LNS pour les appels entrants sont :
repos
Un message Demande d'appel entrant est reçu. Si la demande n'est pas acceptable, une Notification de déconnexion d'appel est renvoyée au LAC et le LNS reste à l'état repos. Si le message Demande d'appel entrant est acceptable, une Réponse d'appel entrant est envoyée. La session passe à l'état attente-connexion.
attente-connexion
Si la session est encore connectée au LAC, celui-ci envoie un message Appel entrant connecté au LNS qui passe alors à l'état établi. Le LAC peut envoyer une Notification d'appel déconnecté pour indiquer que l'appelant entrant pourrait n'être pas connecté. Cela pourrait arriver, par exemple, si un utilisateur du téléphone passe accidentellement un appel vocal standard à un LAC qui résulte en un échec de prise de contact sur le modem appelé.
établi
La session se termine par la réception d'un message Notification d'appel déconnecté provenant du LAC ou par l'envoi d'un Notification d'appel déconnecté. Le nettoyage suit des deux côtés sans considération de qui est l'initiateur.
Les appels sortants sont initiés par un LNS qui donne pour instruction à un LAC de passer un appel. Il y a trois messages pour un appel sortant : Demande d'appel sortant, Réponse d'appel sortant, et Appel sortant connecté. Le LNS envoie une Demande d'appel sortant qui spécifie le numéro de téléphone du demandé, la sous adresse et les autres paramètres. Le LAC DOIT répondre au message Demande d'appel sortant par un message Réponse d'appel sortant une fois que le LAC a déterminé que les facilités appropriées existent pour passer l'appel et que l'appel est administrativement autorisé. Par exemple, ce LNS est il autorisé à composer un appel international ? Une fois l'appel sortant connecté, le LAC envoie un message Appel sortant connecté au LNS pour indiquer le résultat final de la tentative d'appel.
État |
Événement |
Action |
Nouvel état |
repos |
Reçoit OCRQ, acceptable |
Envoi OCRP, support ouvert |
attente-réponse-cs |
repos |
Reçoit OCRQ, non acceptable |
Envoi CDN, nettoie |
repos |
repos |
Reçoit OCRP |
Envoi CDN, nettoie |
repos |
repos |
Reçoit OCCN, CDN |
Nettoie |
repos |
attente-réponse-cs |
Réponse support, tramage détecté |
Envoi OCCN |
établi |
attente-réponse-cs |
Défaillance support |
Envoi CDN, nettoie |
repos |
attente-réponse-cs |
Reçoit OCRQ, OCRP, OCCN |
Envoi CDN, nettoie |
repos |
établi |
Reçoit OCRQ, OCRP, OCCN |
Envoi CDN, nettoie |
repos |
attente-réponse-cs, établi |
Reçoit CDN |
Nettoie |
repos |
établi |
Abandon ligne support, Demande clôture locale |
Envoi CDN, nettoie |
repos |
Les états associés au LAC pour les appels sortants sont :
repos
Si Demande d'appel sortant est reçu par erreur, répondre par une Notification de déconnexion d'appel. Autrement, allouer un canal physique et envoyer une Réponse d'appel sortant. Passer l'appel sortant et passer à l'état attente-réponse-cs.
attenre-réponse-cs
Si l'appel n'est pas achevé ou si un temporisateur arrive à expiration en attendant l'achèvement de l'appel, envoyer une Notification de déconnexion d'appel avec la condition d'erreur appropriée et passer à l'état repos. Si une connexion par circuit commuté est établie et si le tramage est détecté, envoyer un Appel sortant-connecté indiquant la réussite et passer à l'état établi.
établi
Si une Notification de déconnexion d'appel est reçue par le LAC, l'appel de l'opérateur de télécommunications DOIT être libéré via le mécanisme approprié et la session doit être nettoyée. Si l'appel est déconnecté par le client ou l'interface du demandé, un message Notification de déconnexion d'appel DOIT être envoyé au LNS. L'envoyeur du message Notification de déconnexion d'appel retourne à l'état repos après que l'envoi du message est achevé.
État |
Événement |
Action |
Nouvel état |
repos |
Demande ouverture locale |
Initie l'ouverture locale du tunnel |
attente-tunnel |
repos |
Reçoit OCCN, OCRP, CDN |
Nettoie |
repos |
attente-tunnel |
tunnel-ouvert |
Envoi OCRQ |
attente-réponse |
attente-réponse |
Reçoit OCRP, acceptable |
ancune |
attente-connexion |
attente-réponse |
Reçoit OCRP, non acceptable |
Envoi CDN, nettoie |
repos |
attente-réponse |
Reçoit OCCN, OCRQ |
Envoi CDN, nettoie |
repos |
attente-connexion |
Reçoit OCCN |
aucune |
établi |
attente-connexion |
Reçoit OCRQ, OCRP |
Envoi CDN, nettoie |
repos |
repos, attente-réponse, attente-connexion, établi |
Reçoit CDN, |
Nettoie |
repos |
établi |
Reçoit OCRQ, OCRP, OCCN |
Envoi CDN, nettoie |
repos |
attente-réponse, attente-connexion, établi |
Demande clôture locale |
Envoi CDN, nettoie |
repos |
attente-tunnel |
Demande clôture locale |
Nettoie |
repos |
Les états associés au LNS pour les appels sortants sont :
repos, attente-tunnel
Lors de l'initiation d'un appel sortant, un tunnel est d'abord créé, de façon assez semblable aux états repos et attente-tunnel pour un appel entrant au LAC. Une fois le tunnel établi, un message Demande d'appel sortant est envoyé au LAC et la session passe à l'état attente-réponse.
attente-réponse
Si une Notification de déconnexion d'appel est reçue, une erreur est survenue, et la session est nettoyée et retourne au repos. Si une Réponse d'appel sortant est reçue, l'appel est en cours et la session passe à l'état attente-connexion.
attente-connexion
Si une Notification de déconnexion d'appel est reçue, l'appel a échoué ; la session est nettoyée et retourne à repos. Si un Appel sortant connecté est reçu, l'appel a réussi et la session peut maintenant échanger des données.
établi
Si une Notification de déconnexion d'appel est reçue, l'appel s'est terminé pour la raison indiquée dans les codes de résultat et de cause ; la session revient à l'état repos. Si le LNS choisit de terminer la session, il envoie une Notification de déconnexion d'appel au LAC puis nettoie sa session et la met au repos.
La déconnexion d'un tunnel consiste en ce que l'un ou l'autre homologue produit une Notification d'arrêt de connexion de contrôle. l'envoyeur de cette Notification devrait attendre une durée finie pour l'accusé de réception de ce message avant de libérer les informations de commande associées au tunnel. Le receveur de cette Notification devrait envoyer un accusé de réception de la Notification puis libérer les informations de commande associées.
Le moment où libérer un tunnel est une question de mise en œuvre qui n'est pas spécifiée dans le présent document. Une mise en œuvre particulière peut utiliser toute politique appropriée pour déterminer quand libérer une connexion de contrôle. Certaines mises en œuvre peuvent laisser un tunnel ouvert pendant un certain temps ou peut-être indéfiniment après que la dernière session a été libérée pour ce tunnel. D'autres peuvent choisir de déconnecter le tunnel immédiatement après la déconnexion de la dernière connexion d'utilisateur sur le tunnel.
8. L2TP sur supports spécifiques
L2TP est auto-descriptif, fonctionnant à un niveau au dessus du support sur lequel il est porté. Cependant, certaines précisions sur sa connexion au support sont nécessaires pour permettre des mises en œuvre interopérables. Les paragraphes qui suivent décrivent les détails nécessaires à l'interopérabilité sur des supports spécifiques.
L2TP utilise l'accès UDP enregistré 1701 [RFC1700]. Le paquet L2TP tout entier, y compris la charge utile et l'en-tête L2TP, est envoyé au sein d'un datagramme UDP. L'initiateur d'un tunnel L2TP prend un accès de source UDP disponible (qui peut ou non être 1701) et envoie à l'adresse de destination désirée à l'accès 1701. Le receveur prend un accès libre sur son propre système (qui peut être ou non 1701) et envoie sa réponse à l'accès UDP et à l'adresse de l'initiateur, réglant son propre accès de source à l'accès libre qu'il a trouvé. Une fois que les accès de source et de destination et les adresses sont établis, ils DOIVENT rester statiques pour toute la vie du tunnel.
Il a été suggéré que si le receveur choisit un accès de source arbitraire (par opposition à l'utilisation de l'accès de destination qui est dans le paquet qui initie le tunnel, c'est-à-dire, 1701) cela peut rendre plus difficile que L2TP traverse certains appareils de NAT (traducteur d'adresse réseau). Les mises en œuvre devraient en envisager les implications potentielles avant de choisir un accès de source arbitraire.
La fragmentation IP peut survenir alors que le paquet L2TP voyage sur le support IP. L2TP ne fait pas d'efforts particuliers pour optimiser cela. Une mise en œuvre de LAC PEUT être cause que son LCP négocie une MRU spécifique, qui pourrait s'optimiser pour des environnements de LAC dans lesquels la MTU du chemin sur lequel les paquets L2TP vont vraisemblablement voyager a une valeur cohérente.
Par défaut, toute mise en œuvre L2TP DOIT avoir ses sommes de contrôle UDP activées pour les messages à la fois de commande et de données. Une mise en œuvre L2TP PEUT fournir l'option de désactiver les sommes de contrôle UDP pour les messages de données. Il est recommandé que les sommes de contrôle UDP soient toujours activées sur les paquets de commande.
L'accès 1701 est utilisé aussi bien pour les paquets L2F [RFC2341] que L2TP. Le champ Version dans chaque en-tête peut être utilisé pour faire la différence entre les deux types de paquet (L2F utilise une valeur de 1, et la version L2TP décrite dans le présent document utilise une valeur de 2). Une mise en œuvre L2TP fonctionnant sur un système qui ne prend pas en charge L2F DOIT éliminer en silence tous les paquets L2F.
Pour le client PPP qui utilise un tunnel L2TP sur UDP/IP, la liaison PPP a pour caractéristique d'être capable de réarranger ou d'abandonner en silence les paquets. Le réarrangement peut casser les protocoles non IP qui sont portés par PPP, en particulier ceux qui sont centrés sur des LAN tels que les pontages. L'abandon en silence peut casser les protocoles qui supposent une indication d'erreur paquet par paquet, comme la compression d'en-tête TCP. Le séquencement peut être traité en utilisant les numéros de séquence des messages de données L2TP si un protocole transporté par le tunnel PPP ne peut pas tolérer le réarrangement. Les caractéristiques de dépendance à la séquence des différents protocoles sortent du domaine d'application du présent document.
Permettre que les paquets soient abandonnés en silence est peut-être encore plus problématique avec certains protocoles. Si la livraison fiable de PPP [RFC1663] est activée, aucun protocole au dessus de PPP ne va rencontrer de paquet perdu. Si les numéros de séquence L2TP sont activés, L2TP peut détecter la perte de paquet. Dans le cas d'un LNS, les piles PPP et L2TP sont toutes deux présentes au sein du LNS, et la signalisation de perte de paquet peut survenir précisément si un paquet est reçu avec une erreur de CRC. Lorsque le LAC et la pile PPP sont co-résidents, cette technique s'applique aussi. Lorsque le LAC et le client PPP sont physiquement distincts, la signalisation analogique PEUT être réalisée par l'envoi d'un paquet avec une erreur de CRC au client PPP. Noter que cela augmenterait de beaucoup la complexité des problèmes de débogage de ligne client, car les statistiques de client ne pourraient pas distinguer entre les erreurs de support et celles générées par le LAC. De plus, cette technique n'est pas possible sur tous les matériels.
Si la compression VJ est utilisée, et si ni la livraison PPP fiable ni les numéros de séquence ne sont activés, chaque paquet perdu résulte en une chance sur 2**16 qu'un segment TCP soit transmis avec un contenu incorrect [RFC1144]. Lorsque la combinaison du taux de perte de paquet et de cette donnée statistique est inacceptable, la compression d'en-tête TCP NE DEVRAIT PAS être utilisée.
En général, il est bon de se rappeler que le transport L2TP/UDP/IP n'est pas un transport fiable. Comme avec tout support PPP sujet à la perte, il faut faire attention quand on utilise des protocoles qui sont particulièrement sensibles aux pertes. De tels protocoles incluent les protocoles de compression et de chiffrement qui emploient un historique.
Lorsque il fonctionne dans des environnements IP, L2TP DOIT offrir l'encapsulation UDP décrite en 8.1 comme configuration par défaut pour le fonctionnement sur IP. D'autres configurations (peut-être correspondant à un format d'en-tête compressé) PEUVENT être définies et rendues disponibles comme option configurable.
9. Considérations pour la sécurité
Le fonctionnement de L2TP soulève plusieurs problèmes de sécurité. L'approche générale de ces problèmes par L2TP est exposée ci-dessous.
9.1 Sécurité de point d'extrémité de tunnel
Les points d'extrémité de tunnel peuvent facultativement effectuer une procédure d'authentification réciproque durant l'établissement du tunnel. Cette authentification a les mêmes attributs de sécurité que CHAP, et offre une protection raisonnable contre les attaques en répétition et l'espionnage durant le processus d'établissement du tunnel. Ce mécanisme n'est pas conçu pour assurer d'authentification au delà de l'établissement du tunnel ; il est très facile à un malveillant qui peut espionner le tunnel d'injecter des paquets une fois qu'un établissement de tunnel authentifié a été achevé avec succès.
Pour que l'authentification se fasse, le LAC et le LNS DOIVENT partager un seul secret. Chaque côté utilise ce même secret lorsque il agit comme authentifié aussi bien que comme authentificateur. Comme un seul secret est utilisé, les AVP d'authentification de tunnel comportent des valeurs de différentiation dans le champ Identifiant CHAP pour chaque calcul de résumé de message pour se garder contre les attaques en répétition.
L'identifiant de tunnel alloué et l'identifiant de session alloué (voir au paragraphe 4.4.3) DEVRAIENT être choisis de façon imprévisible plutôt que séquentielle ou autre. Le faire aidera à empêcher le détournement d'une session par un malveillant qui n'a pas accès aux traces du paquet entre le LAC et le LNS.
Sécuriser L2TP exige que le transport sous-jacent offre des services de chiffrement, d'intégrité et d'authentification pour tout le trafic L2TP. Ce transport sûr fonctionne sur le paquet L2TP entier et est fonctionnellement indépendant de PPP et du protocole porté par PPP. À ce titre, L2TP est seulement concerné par la confidentialité, l'authenticité, et l'intégrité des paquets L2TP entre ses points d'extrémité de tunnel (le LAC et le LNS) un peu comme le chiffrement de couche liaison est seulement concerné par la protection de la confidentialité du trafic entre ses points d'extrémité physiques.
La protection du flux de paquets L2TP via un transport sûr protège aussi à son tour les donnés au sein des paquet PPP tunnelés lors du transport du LAC au LNS. Une telle protection ne devrait pas être considérée comme une substitution à la sécurité de bout en bout entre les hôtes ou applications communicants.
Lorsque il fonctionne sur IP, IPsec procure une sécurité au niveau du paquet via ESP (charge utile de sécurité par encapsulage) /ou AH (en-tête d'authentification). Tous les paquets L2TP de commande et de données pour un tunnel particulier apparaissent comme des paques UDP/IP homogènes au système IPsec.
En plus de la sécurité du transport IP, IPsec définit un mode de fonctionnement qui permet le tunnelage des paquets IP. Le chiffrement et l'authentification de niveau paquet fournis par le mode tunnel IPsec et ceux fournis par L2TP sécurisé avec IPsec fournissent un niveau équivalent de sécurité pour ces exigences.
IPsec définit aussi des caractéristiques de contrôle d'accès qui sont exigées pour qu'une mise en œuvre soit conforme à IPsec. Ces caractéristiques permettent le filtrage des paquets sur la base des caractéristiques de couche réseau et transport telles que l'adresse IP, les accès, etc. Dans le modèle de tunnelage L2TP, le filtrage analogique est effectué logiquement à la couche PPP ou à la couche réseau au dessus de L2TP. Ces caractéristiques de contrôle d'accès de couche réseau peuvent être traitées au LNS via des dispositifs d'autorisation spécifiques du fabricant sur la base de l'utilisateur PPP authentifié, ou à la couche réseau elle-même en utilisant le mode transport IPsec de bout en bout entre les hôtes communicants. Les exigences des mécanismes de contrôle d'accès ne font pas partie de la spécification L2TP et à ce titre sortent du domaine d'application du présent document.
9.5 Authentification de mandataire PPP
L2TP définit des AVP qui PEUVENT être échangées durant l'établissement de session pour fournir au LNS, aux fins de validation, la transmission des informations d'authentification PPP obtenues du LAC (voir au paragraphe 4.4.5). Cela implique une relation de confiance directe du LNS au LAC. Si le LNS choisit de mettre en œuvre l'authentification du mandataire, il DOIT être capable d'être configuré pour cela, ce qui exige un nouveau cycle d'authentification PPP initié par le LNS (qui peut ou non inclure un nouveau cycle de négociation LCP).
10. Considérations relatives à l'IANA
Le présent document définit un certain nombre de numéros "magiques" qui sont conservés par l'IANA. Cette section explique les critères qu'utilise l'IANA pour allouer des numéros supplémentaires dans chacune de ces listes. Les paragraphes suivants décrivent la politique d'allocation des espaces de noms définis ailleurs dans ce document.
Comme défini au paragraphe 4.1, les AVP contiennent des champs Identifiant de fabricant, Attribut et Valeur. Pour la valeur d'identifiant de fabricant de 0, l'IANA tiendra un registre des attributs alloués et dans certains cas aussi des valeurs. Les attributs 0 à 39 sont alloués comme défini au paragraphe 4.4. Les valeurs restantes sont disponibles pour l'allocation par consensus de l'IETF [RFC 2434].
10.2 Valeurs d'AVP Type de message
Comme défini au paragraphe 4.4.1, les AVP Type de message (type d'attribut 0) ont une valeur associée conservée par l'IANA. Les valeurs 0 à 16 sont définies au paragraphe 3.2, les valeurs restantes sont disponibles pour une allocation via le consensus de l'IETF [RFC 2434]
10.3 Valeurs d'AVP Code de résultat
Comme défini au paragraphe 4.4.2, les AVP Code de résultat (type d'attribut 1) contiennent trois champs. Deux de ces champs (Code de résultat et Code d'erreur) ont des valeurs associées conservées par l'IANA.
L'AVP Code de résultat peut être incluse dans les messages CDN et StopCCN. Les valeurs admissibles pour le champ Code de résultat de l'AVP diffèrent selon la valeur de l'AVP Type de message. Pour le message StopCCN, les valeurs 0 à 7 sont définies au paragraphe 4.4.2 ; pour le message StopCCN, les valeurs 0 à 11 sont définies au même paragraphe. Les valeurs restantes du champ Code de résultat pour les deux messages sont disponibles pour être allouées via consensus de l'IETF [RFC 2434].
Les valeurs 0 à 7 sont définies au paragraphe 4.4.2. Les valeurs 8 à 32767 sont disponibles pour être allouées via consensus de l'IETF [RFC 2434]. Les valeurs restantes du champ Code d'erreur sont disponibles pour être allouées au premier qui les demande [RFC 2434].
10.4 Capacités de tramage et capacités du support
L'AVP Capacités de tramage et l'AVP Capacités du support (définies au paragraphe 4.4.3) contiennent toutes deux des gabarits binaires de 32 bits. Des bits supplémentaires ne devraient être définis que via une action de normalisation [RFC 2434].
10.5 Valeurs d'AVP Type d'authentification de mandataire
L'AVP Type d'authentification de mandataire (type d'attribut 29) a une valeur associée conservée par l'IANA. Les valeurs 0 à 5 sont définies au paragraphe 4.4.5, les valeurs restantes sont disponibles pour allocation au premier qui les demande [RFC 2434].
Il y a quatre bits réservés restants dans l'en-tête d'AVP. Des bits supplémentaires ne devraient être alloués que via une action de normalisation [RFC 2434].
[DSS1] Recommandation UIT-T Q.931 (I.451), "Système n° 1 de signalisation d'abonné numérique (DSS 1) – spécification de la commande d'appel de base pour l'interface usager RNIS – réseau à la couche 3", mai 1998.
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, mars1995, ISBN 0-13-061466-1
[RFC791] J. Postel, "Protocole Internet", STD 5, septembre 1981.
[RFC1034] P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.
[RFC1144] V. Jacobson, "Compression des en-têtes TCP/IP pour les liaisons série à faible débit", février 1990.
[RFC1661] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC 2153)
[RFC1662] W. Simpson, éditeur, "PPP en trames de style HDLC", STD 51, juillet 1994. (Remplace la RFC 1549)
[RFC1663] D. Rand, éditeur, "Transmission fiable en PPP", juillet 1994. (P.S.)
[RFC1700] J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1700, octobre 1994. (Historique, voir http://www.iana.org/numbers.html
[RFC1990] K. Sklower et autres, "Protocole multiliaison en PPP (MP)", août 1996. (Remplace RFC1717) (D.S.)
[RFC1994] W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", août 1996.
[RFC1918] Y. Rekhter et autres, "Allocation d'adresse pour les internets privés", février 1996.
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Service d'authentification distante d'utilisateur appelant (RADIUS)", avril 1997. (Remplace RFC2058) (Obsolète, voirRFC2865) (P.S.)
[RFC2277] H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", BCP 18, janvier 1998.
[RFC2341] A. Valencia, M. Littlewood, T. Kolar, "Protocole de transmission de couche 2 "L2F" de Cisco", mai 1998. (Historique)
[RFC2401] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voirRFC4301)
[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)
[RFC2637] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little et G. Zorn, "Protocole de tunnelage point à point (PPTP)", juillet 1999.
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., mars 1996, ISBN 0-201-63346-9
Le concept de base de L2TP et beaucoup des constructions de son protocole ont été tirés de L2F [RFC2341] et de [PPTP]. Leurs auteurs sont A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little et G. Zorn.
Dory Leifer a apporté des améliorations précieuses à la définition du protocole de L2TP et a contribué à l'édition de ce document.
Steve Cobb et Evan Caves ont revu la conception des tableaux des machines d'état.
Barney Wolff a fourni une grand quantité d'apports de concepts sur le mécanisme d'authentification des points d'extrémité.
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer et Rich Shea ont fourni des apports précieux et des révisions à la 43 ème réunion de l'IETF à Orlando, FL., qui ont conduit à améliorer la lisibilité globale et la clarté de ce document.
Gurdeep Singh Pall |
Bill Palter |
Allan Rubens |
Microsoft Corporation |
RedBack Networks, Inc |
Ascend Communications |
Redmond, WA |
1389 Moffett Park Drive |
1701 Harbor Bay Parkway |
|
Sunnyvale, CA 94089 |
Alameda, CA 94502 |
mél : gurdeep@microsoft.com |
mél : palter@zev.net |
mél : acr@del.com |
W. Mark Townsley |
Andrew J. Valencia |
Glen Zorn |
cisco Systems |
cisco Systems |
Microsoft Corporation |
7025 Kit Creek Road |
170 West Tasman Drive |
One Microsoft Way |
PO Box 14987 |
San Jose CA 95134-1706 |
Redmond, WA 98052 |
Research Triangle Park, NC 27709 |
|
|
mél : townsley@cisco.com |
mél: vandys@cisco.com |
mél : gwz@acm.org |
Appendice A Démarrage lent et évitement d'encombrement du canal de contrôle
Bien que chaque côté ait indiqué la taille maximum de sa fenêtre de réception, il est recommandé qu'une méthode de démarrage lent et d'évitement d'encombrement soit utilisée pour transmettre les paquets de contrôle. Les méthodes décrites ici se fondent sur l'algorithme TCP d'évitement d'encombrement décrit au paragraphe 21.6 de TCP/IP Illustré, volume I, de W. Richard Stevens [STEVENS].
Le démarrage lent et l'évitement d'encombrement utilisent plusieurs variables.
La fenêtre d'encombrement (CWND, congestion window) définit le nombre de paquets qu'un envoyeur peut émettre avant d'attendre un accusé de réception. La taille de CWND s'étend et se contracte comme décrit ci-dessous. Noter cependant, qu'il n'est jamais permis que CWND excède la taille de la fenêtre annoncée obtenue de l'AVP Fenêtre de réception (dans le texte ci-dessous, on suppose que toute augmentation sera limitée par la taille de fenêtre de réception). La variable SSTHRESH détermine quand l'envoyeur passe du démarrage lent à l'évitement d'encombrement. Le démarrage lent est utilisé lorsque CWND est inférieur à SSTHRESH.
Un envoyeur commence par la phase de démarrage lent. CWND est initialisé à un paquet, et SSTHRESH est initialisé à la fenêtre annoncée (obtenue de l'AVP Fenêtre de réception). L'envoyeur transmet alors un paquet et attend son accusé de réception (explicite ou porté). Lorsque l'accusé de réception est reçu, la fenêtre d'encombrement est incrémentée de un à deux. Durant le démarrage lent, CWND est augmenté d'un paquet chaque fois qu'un ACK (ZLB explicite ou porté) est reçu. Augmenter CWND de un à chaque ACK a pour effet de doubler CWND à chaque aller-retour, ce qui résulte en une augmentation exponentielle. Lorsque la valeur de CWND atteint SSTHRESH, la phase de démarrage lent se termine et la phase d'évitement d'encombrement commence.
Durant l'évitement d'encombrement, CWND s'étend plus lentement. Précisément, il augmente de 1/CWND pour chaque nouvel ACK reçu. C'est-à-dire que CWND est augmenté de un paquet après que CWND nouveaux ACK ont été reçus. L'expansion de fenêtre durant la phase d'évitement d'encombrement est effectivement linéaire, CWND s'accroissant de un paquet à chaque aller-retour.
Lorsque survient de l'encombrement (indiqué par le déclanchement d'une retransmission) une moitié de CWND est sauvegardée dans SSTHRESH, et CWND est réglé à un. L'envoyeur revient alors à la phase de démarrage lent.
Appendice B Exemples de message de commande
B.1 Établissement de tunnel verrouillé
Dans cet exemple, un LAC établit un tunnel, avec l'échange qui implique que chaque côté envoie des messages en alternance. Cet exemple montre l'accusé de réception final envoyé explicitement au sein d'un message ACK ZLB. Une autre solution serait de faire porter l'accusé de réception au sein d'un message envoyé en réponse à l'ICRQ ou OCRQ qui va vraisemblablement suivre de la part du côté qui a pris l'initiative du tunnel.
LAC ou LNS |
LNS ou LAC |
SCCRQ ---> |
|
Nr : 0, Ns : 0 |
|
|
<--- SCCRP |
|
Nr : 1, Ns : 0 |
SCCCN ---> |
|
Nr : 1, Ns : 1 |
|
|
<--- ZLB |
|
Nr : 2, Ns : 1 |
B.2 Paquet perdu avec retransmission
Un tunnel existant a une nouvelle session demandée par le LAC. Le ICRP est perdu et doit être retransmis par le LNS. Noter que la perte de l'ICRP a deux impacts : non seulement elle empêche l'automate à états de niveau supérieur d'avancer, mais elle empêche aussi le LAC de voir à temps un accusé de réception de niveau inférieur de son ICRQ.
LAC |
LNS |
ICRQ -> |
|
Nr: 1, Ns: 2 |
|
(paquet perdu) |
<--- ICRP |
|
Nr : 3, Ns : 1 |
(pause ; le temporisateur du LAC a commencé |
le premier et donc arrive le premier à expiration) |
ICRQ ---> |
|
Nr : 1, Ns : 2 |
|
(Réalisant qu'il a déjà vu ce paquet, |
le LNS l'élimine et envoie un ZLB) |
|
<--- ZLB |
|
Nr : 3, Ns : 2 |
|
(le temporisateur du LNS arrive à expiration) |
|
<--- ICRP |
|
Nr : 3, Ns : 1 |
ICCN ---> |
|
Nr : 2, Ns : 3 |
|
|
<--- ZLB |
|
Nr : 4, Ns : 2 |
Appendice C : Notice de propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqué au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IIETF au sujet des droits dans les documents en cours de normalisation et ceux qui se rapportent aux normes se trouvent dans le BCP-11. Des copies des revendications de droits rendues disponibles pour la publication et toutes les assurances que des licences seront rendues disponibles, ou le résultat de tentatives pour obtenir une licence générale ou une permission d'utilisation de tels droits de propriété pour la mise en œuvre ou l'utilisation de la présente spécification peuvent être obtenues au Secrétariat de l'IETF.
L'IETF invite toute partie intéressée à porter à son attention tous droits de reproduction, brevets ou demandes de brevets, ou autres droits de propriété qui pourraient couvrir des technologies qui pourraient être nécessaire pour mettre cette norme en pratique. Prière d'adresser les informations au Directeur exécutif de l'IETF.
Il a été notifié à l'IETF que des droits de propriété intellectuelle sont revendiqués à l'égard de certaines ou de toutes les spécifications contenues dans le présent document. Pou plus d'informations, consulter la liste en ligne des droits revendiqués.
Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2000). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY et L'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.
Remerciement
Le financement de la fonction d'éditeur des RFC est actuellement fourni par la Internet Society.