| Groupe de Travail sur les Réseaux Requête pour Commentaires : 1332 - FR Rend obsolète : RFC 1172 Traduction : Yves LESCOP (lycée la croix-rouge - Brest) |
Ce document spécifie un protocole standard d'Internet pour la communauté Internet, et ne sera éprouvé qu'après plusieurs discussions et suggestions. Merci de vous référer à l'édition courante du " Internet Official Protocol Standards " (STD1) pour l'état de standardisation et le statut de ce protocole. La distribution de ce document est illimitée.
Le Protocole Point à Point (PPP) [1] fournit une méthode standard pour encapsuler l'information du protocole de couche réseau au-dessus de liens point à point. Le PPP définit également un protocole extensible de contrôle de lien, et propose une famille de protocoles de contrôle de réseau (NCPs) pour établir et configurer différents protocoles de couche réseau.
Ce document définit le NCP pour établir et configurer le protocole Internet [2] sur PPP, et une méthode pour négocier et utiliser la compression d'en-tête TCP/IP de Van Jacobson [3] avec PPP.
Ce RFC est un produit du groupe de travail du protocole Point à Point de l'IETF (Internet Engineering Task Force).
PPP a trois composants principaux :
Afin d'établir des transmissions au-dessus d'une liaison point à point, chaque extrémité du lien PPP doit d'abord envoyer des paquets LCP pour configurer et tester la liaison de données. Après que le lien a été établi et que des facilités optionnelles ont été négociées comme nécessaires par le LCP, le PPP doit envoyer des paquets NCP pour choisir et configurer un ou plusieurs protocoles de couche réseau. Une fois configuré chacun des protocoles de couche réseau choisi, des datagrammes de chaque protocole de couche réseau peuvent être envoyés sur le lien.
Le lien demeurera configuré pour des transmissions jusqu'à ce que des paquets LCP ou NCP ferment explicitement le lien, ou jusqu'à ce qu'un certain événement externe se produise (l'expiration d'un temporisateur d'inactivité ou l'intervention d'un administrateur réseau).
Le protocole de contrôle d'IP (IPCP "IP Control Protocol") est responsable de la configuration, de l'autorisation, et de l'invalidation des modules de protocole d'IP sur les deux extrémités de la liaison point à point. IPCP utilise le même mécanisme d'échange de paquet que le protocole de contrôle de lien (LCP). Des paquets IPCP ne peuvent être échangés jusqu'à ce que PPP ait atteint la phase de protocole de couche réseau. Des paquets IPCP reçus avant que cette phase ne soit atteinte devraient être silencieusement jetés.
Le protocole de contrôle d'IP est exactement le même que le protocole de contrôle du lien [1] aux exceptions suivantes :
Champ Protocole de Couche liaison de données :
Exactement un paquet IPCP est encapsulé dans le champ information des trames de couche liaison de données de PPP où le champ protocole indique le type hexadécimal 8021 (IPCP).
Champ Code :
Seulement les codes 1 à 7 ("Demande-Configuration", "ACK-Configuration", "NAK-Configuration", "Rejet-Configuration", "Demande-Terminaison", "ACK-Terminaison" et "Rejet-Code") sont utilisés. Les autres codes devraient être traités comme non reconnus et devraient avoir comme conséquence "Rejet-Code".
Minuteries :
Des paquets IPCP ne peuvent être échangés jusqu'à ce que PPP ait atteint la phase de protocole de couche réseau. Une implémentation devrait être préparée pour attendre l'authentification et que la détermination de la qualité du lien soit terminée avant le déclenchement d'une fin d'attente pour un "ACK-Configuration" ou toute autre réponse. Il est suggéré qu'une implémentation abandonne seulement après l'intervention d'un utilisateur ou un délai configurable.
Types d'Option de Configuration :
IPCP a un ensemble distinct d'options de configuration, qui sont définies ci-dessous.
Avant que tous les paquets IP puissent être communiqués, PPP doit atteindre la phase de protocole de couche réseau, et le protocole de contrôle d'IP doit atteindre l'état ouvert.
Exactement un paquet IP est encapsulé dans le champ information des trames de couche liaison de données PPP où le champ protocole indique le type hexadécimal 0021 (Internet Protocol).
La longueur maximum d'un paquet IP transmis au-dessus d'un lien PPP est la même que la longueur maximum du champ information d'une trame de couche liaison de données PPP. De plus grands datagrammes IP doivent être fragmentés si nécessaire. Si un système souhaite éviter la fragmentation et le réassemblage, il devrait utiliser l'option taille maximum de segment de TCP [4], et la découverte du MTU [5].
Les options de configuration d'IPCP permettent la négociation des paramètres souhaitables d'IP. IPCP utilise le même format d'option de configuration que celui défini pour LCP [1], avec un jeu séparé d'options.
Les valeurs les plus à jour du champ type d'option IPCP sont indiquées dans le RFC "nombres assignés" [6] le plus récent. Les valeurs actuelles sont assignées comme suit :
Description :
L'utilisation de l'option de configuration "Adresses-IP" a été désapprouvée. L'expérience des mises en place a déterminé qu'il est difficile en utilisant cette option d'assurer la convergence de la négociation dans tous les cas. RFC 1172 [7] fournit des informations pour les implémentations exigeant cette compatibilité. L'option de configuration d'adresse IP se substitue à cette option, et son utilisation est préférable.
Cette option NE DEVRAIT PAS être émise dans une demande de configuration si une "demande-configuration" a été reçue qui inclut une option "Adresses-IP" ou "Adresse-IP". Cette option PEUT être envoyée si "Rejet-Configuration" est reçu pour l'option "Adresse-IP", ou un "NAK-Configuration" est reçu avec l'option "adresses-IP" comme option ajoutée.
Le soutien de cette option PEUT être enlevé après que le statut du protocole IPCP avance au stade de projet de norme d'Internet.
Description :
Cette option de configuration fournit une voie pour négocier l'utilisation d'un protocole spécifique de compression. Par défaut, la compression n'est pas permise.
Un récapitulatif du format de l'option de configuration du Protocole de compression IP est montré ci-dessous. Les champs sont transmis de gauche à droite.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Longueur | Protocole compression IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données ...
+-+-+-+-+
Type : 2
Longueur : >= 4
Protocole de compression IP : Le champ "Protocole-compression-IP" est de deux octets et indique le protocole de compression désiré. Les valeurs pour ce champ sont toujours identiques à celles du champ de protocole de couche liaison de données PPP pour ce même protocole de compression.
Les valeurs les plus à jour du champ "Protocole-compression-IP" sont indiquées dans le RFC "nombres assignés" [6] le plus récent. Les valeurs actuelles sont assignées comme suit :
| Valeur (en hexa) |
Protocole |
| 002d |
Compression TCP/IP Van Jacobson |
Données : Le champ d'information est de zéro octets ou plus et contient des données supplémentaires comme déterminé par le protocole particulier de compression.
Par Défaut : Aucun protocole de compression n'est permis.
Description :
Cette option de configuration fournit une voie pour négocier l'adresse IP à utiliser sur l'extrémité locale du lien. Elle permet à l'expéditeur du "Demande-Configuration" d'énoncer quelle adresse IP est désirée, ou pour demander que le pair fournisse les informations. Le pair peut fournir ces informations par le rejet de l'option, et en renvoyant une adresse IP valide.
Si la négociation au sujet de l'adresse IP distante est nécessaire, et le pair ne fournit pas l'option dans sa "Demande-Configuration", l'option DEVRAIT être ajoutée à un "NAK-Configuration". La valeur de l'adresse IP donnée doit être acceptable en tant qu'adresse IP distante, ou indique une demande pour que le pair fournisse l'information.
Par défaut, aucune adresse IP n'est assignée.
Un récapitulatif du format d'option de configuration de l'adresse IP est montré ci-dessous. Les champs sont transmis de gauche à droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Longueur | Adresse IP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adresse IP (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : 3
Longueur : 6
Adresse IP : Les quatre octets d'adresse IP est l'adresse locale désirée par l'expéditeur de la demande de configuration. Si chacun des quatre octets est mis à zéro, cela indique une demande pour que le pair fournisse l'information d'adresse IP.
Par Défaut : Aucune adresse IP n'est assignée.
La compression d'en-tête TCP/IP de Van Jacobson ramène la taille des en-têtes de TCP/IP à seulement trois octets. Ceci peut être une amélioration significative sur les lignes séries lentes, en particulier pour le trafic interactif.
L'option de configuration de "Protocole-Compression-IP" est employée pour indiquer la capacité de recevoir les paquets comprimés. Chaque extrémité du lien doit demander séparément cette option si la compression bidirectionnelle est désirée.
Le champ protocole PPP est positionné aux valeurs suivantes lors de la transmission des paquets IP :
| Valeur (en hexa) |
|
| 0021 |
Type IP. Le protocole d'IP n'est pas TCP, ou le paquet est un fragment, ou ne peut pas être compressé. |
| 002d |
TCP compressé. Les en-têtes de TCP/IP sont remplacés par l'en-tête comprimé. |
| 002f |
TCP Non comprimé. Le champ protocole IP est remplacé par l'identificateur de créneau. |
Un récapitulatif du format d'option de configuration du protocole de compression IP pour négocier la compression d'en-tête TCP/IP de Van Jacobson est montré ci-dessous. Les champs sont transmis de gauche à droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Longueur | Protocole-Compression-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Slot-Id | Comp-Slot-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : 2
Longueur : 6
"Protocole-Compression-IP" : 002d (hexa) pour des en-têtes de TCP/IP comprimées Van Jacobson.
"Max-Slot-Id" : Le champ "Max-Slot-Id" est d'un octet et indique l'identificateur maximum de créneau. C'est un de moins que le nombre réel de créneaux ; l'identificateur de créneau a des valeurs de zéro à "Max-Slot-Id".
Note : Il peut y avoir des réalisations qui ont des problèmes avec seulement un créneau ("Max-Slot-Id" = 0). Voyez la discussion dans la référence [3]. L'exemple de mise en place dans [3] fonctionnera seulement avec de 3 à 254 créneaux.
"Comp-Slot-Id" : Le champ "Comp-Slot-Id" est d'un octet et indique si la zone d'identificateur de créneau peut être comprimée.
L'identificateur de créneau ne doit pas être comprimé si le niveau de lien de PPP n'a aucune aptitude pour indiquer une erreur dans la réception au module de décompression. La synchronisation après des erreurs dépend de la réception d'un paquet avec l'identificateur de créneau. Voir la discussion dans la référence [3].
Les options de configurations suivantes sont recommandées :
"Protocole-Compression-IP" -- avec au moins 4 créneaux, habituellement 16 créneaux.
"Adresse-IP" -- seulement sur les lignes commutées.
Les problèmes de sécurité ne sont pas abordés dans ce document.
[1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
[2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.
[3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January 1990.
[5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
Une partie du texte dans ce document est prise des RFCs 1171 et 1172, par Drew Perkins de "Carnegie Mellon University", et par Russ Hobby de "University of California at Davis".
L'information menant à l'option ajoutée "Compression-IP" fournie par Van Jacobson à "SIGCOMM '90".
Bill Simpson a aidé au formatage du document.
Le groupe de travail peut être contacté par le siège courant :
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@ray.lloyd.com
Les questions sur ce document peuvent aussi être adressée à :
Glenn McGregor
Merit Network, Inc.
1071 Beal Avenue
Ann Arbor, MI 48109-2103
Phone: (313) 763-1203
EMail: Glenn.McGregor@Merit.edu