Groupe de travail sur les réseaux	G. McGregor
Requête pour Commentaires : 1332	Merit
Rend obsolète : RFC 1172	mai 1992
Traduction : Yves lescop	Lycée la croix-rouge - Brest

Protocole de contrôle du protocole Internet sur PPP
IPCP (Internet Protocol Control Protocol)

Statut de ce document

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.

Résumé

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

Table des matières

1	Introduction	2
2	Un protocole de contrôle réseau de PPP (NCP) pour l'IP	3
2.1	Envoi de Datagrammes IP	3
3	Options de Configuration d'IPCP	4
3.1 Adresses IP	4
3.2 Protocole de compression IP	4
3.3 Adresse-IP	5
4	Compression d'en-tête TCP/IP de Van Jacobson	6
4.1	Format d'Option de Configuration	7
A. Options Recommandées par IPCP	7
Considérations Sécuritaires	8
Références	8
Remerciements	8
Adresse du comité	8
Adresse de l'auteur	9

1	Introduction

PPP a trois composants principaux :

1.	Une méthode pour encapsuler les datagrammes sur les liaisons séries.

2.	Un protocole de contrôle du lien (LCP "Link Control Protocol") pour établir, configurer, et tester la connexion du lien de données.

3.	Une famille de protocoles de contrôle de réseau (NCPs) pour établir et configurer différents protocoles de couche réseau.

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

2	Un protocole de contrôle réseau de PPP (NCP) pour l'IP

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.

2.1	Envoi de Datagrammes IP

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

3	Options de Configuration d'IPCP

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 :

1.	Adresses IP
2.	Protocole de compression IP
3.	Adresse IP.

3.1 Adresses IP

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.

3.2 Protocole de compression IP

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

3.3 Adresse-IP

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.

4	Compression d'en-tête TCP/IP de Van Jacobson 

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.	

4.1	Format d'Option de Configuration

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.

0  l'identificateur de créneau ne doit pas être comprimé. Tous les paquets comprimés de TCP doivent placer le bit C dans chaque masque de changement, et doivent inclure l'identificateur de créneau.

1  l'identificateur de créneau peut être comprimé.

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

A. Options Recommandées par IPCP

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.

Considérations Sécuritaires

Les problèmes de sécurité ne sont pas abordés dans ce document.

Références

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

[4]   Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983.

[5]   Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

[6]   Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.

[7]   Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) initial configuration options", RFC 1172, August 1990.

Remerciements

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.

Adresse du comité

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

Adresse de l'auteur

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