Groupe de travail Réseau	T. Koren, Cisco Systems	
Request for Comments : 3544	S. Casner, Packet Design	
RFC rendue obsolète : 2509	C. Bormann, Universitaet Bremen TZI	
Catégorie :En cours de normalisation	juillet 2003	
Traduction Claude Brière de L’Isle 	septembre 2007	

Compression d’en-tête IP sur PPP

Statut du présent Mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD  1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.

Notice de copyright

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

Résumé

Le présent document décrit une option pour la négociation de l’utilisation de la compression d’en-tête sur les datagrammes IP transmis avec le protocole point à point (RFC 1661). Il définit les extensions aux protocoles de commande PPP pour IPv4 et IPv6 (RFC 1332, RFC 2472). La compression d’en-tête peut être appliquée aux datagrammes IPv4 et IPv6 en combinaison avec les protocoles de transport TCP, UDP et RTP, comme spécifié dans les RFC 2507, RFC 2508 et RFC 3545.

1	Introduction

La compression d’en-tête IP (IPHC, IP Header Compression) définie dans la [RFC2507] peut être utilisée pour la compression des datagrammes IPv4 aussi bien que IPv6 ou des paquets encapsulés avec plusieurs en-têtes IP. IPHC est aussi capable de compresser des en-têtes de protocole de transport TCP et UDP. La compression d’en-tête IP/UDP/RTP définie dans la [RFC2508] et la [RFC3545] convient dans le cadre de travail défini par IPHC de sorte qu’elle peut aussi s’appliquer à la fois aux paquets IPv4 et IPv6.

Pour établir la compression de datagrammes IP envoyés sur une liaison PPP, chaque extrémité de la liaison doit se mettre d’accord sur un ensemble de paramètres de configuration pour la compression. Le processus de négociation des paramètres de liaison pour les protocoles de couche réseau est traité dans PPP par une famille de protocole de commande de réseau (NCP, network control protocol). Comme il y a des NCP distincts pour IPv4 et IPv6, le présent document définit des options de configuration à utiliser dans les deux NCP pour négocier les paramètres pour le schéma de compression.

Le présent document rend obsolète la RFC 2509, en ajoutant deux nouvelles sous options à l’option de configuration de compression d’en-tête IP. Une sous option négocie l’usage de la Compression RTP améliorée (spécifiée dans la [RFC3545]), et l’autre sous option négocie la compression d’en-tête seulement pour TCP ou seulement pour les paquets non TCP.

IPHC s’appuie sur la capacité de la couche de liaison à indiquer les types de datagrammes portés dans les trames de couche de liaison. Dans le présent document sont définis neuf nouveaux types pour le champ Protocole de couche liaison des données PPP avec leur signification.

En général, les schémas de compression qui utilisent le différentiel de codage des paquets compressés exigent que la couche inférieure ne réorganise pas les paquets entre le compresseur et le décompresseur. IPHC utilise le différentiel de codage des paquets compressés pour TCP et RTP. La spécification IPHC [RFC2507] inclut pour utiliser avec IPHC des méthodes qui permettent des couches de liaison qui peuvent réordonner les paquets. Comme PPP ne réordonne pas les paquets, ces mécanismes sont désactivés par défaut. Lors de l’utilisation de mécanisme de réordonnancement comme PPP multi liaison multi classes [RFC2686], il faut veiller à ce que les paquets qui partagent le même contexte de compression ne soient pas réordonnés.

2	Option de configuration

Le présent document spécifie une nouvelle valeur de protocole de compression pour les options de IPCP (IP-Compression-Protocol) spécifiées dans la [RFC1332]. La nouvelle valeur et le format d’option associée sont décrits au paragraphe 2.1.

Le format d’option est structuré pour permettre des extensions futures du schéma IPHC.

NOTE : La spécification de la négociation de paramètre de couche liaison et réseau pour PPP [RFC1661], [RFC1331], [RFC1332] n’interdit pas plusieurs instances d’une option de configuration mais établit que la spécification d’une option de configuration doit explicitement permettre plusieurs instances. La [RFC3241] met à jour la RFC 1332 en permettant explicitement l’envoi de plusieurs instances de l’option de configuration de IP-Compression-Protocol, ayant chacune une valeur différente pour IP-Compression-Protocol. Chaque type de protocole de compression peut établir indépendamment ses propres paramètres.

NOTE : La [RFC1332] n’est pas explicite sur le point de savoir si l’option négocie les capacités du receveur ou de l’expéditeur. En collant aux pratiques courantes, on suppose que l’option décrit les capacités du décompresseur (côté receveur) de l’homologue qui envoie la demande Config-Req.

2.1	Format d’option de configuration

Le protocole de commande de réseau pour IPv4, IPCP [RFC1332] et le NCP IPv6 NCP, IPV6CP [RFC2472] peuvent tous deux être utilisés pour négocier les paramètres de compression d’en-tête IP pour leurs protocoles respectifs. Le format de l’option de configuration est le même pour IPCP et pour IPV6CP.

Description

Cette option de configuration NCP est utilisée pour négocier les paramètres pour la compression d’en-tête IP. Une négociation réussi des paramètre permet l’utilisation des identifiants de protocole FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP et CONTEXT_STATE comme spécifié dans la [RFC2507]. Le format d’option est résumé 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	IP-Compression-Protocol	
TCP_SPACE	NON_TCP_SPACE	
F_MAX_PERIOD	F_MAX_TIME	
MAX_HEADER	sous options...	

Type : 2

Longueur : ≥ 14

La longueur peut être augmentée si la présence de paramètres supplémentaires est indiquée par des sous options additionnelles.

IP-Compression-Protocol  : 0061 (hexadécimal)

TCP_SPACE
Le champ TCP_SPACE est de deux octets et indique la valeur maximum d’un identifiant de contexte dans l’espace des identifiants de contexte alloués pour TCP.

Valeur suggérée : 15

TCP_SPACE doit être au moins de 0 et au plus de 255 (la valeur 0 implique d’avoir un contexte).

NON_TCP_SPACE
Le champ NON_TCP_SPACE est de deux octets et indique la valeur maximum d’un identifiant de contexte dans l’espace des identifiants de contexte alloués pour le non TCP. Ces identifiants de contexte sont portés dans les en-têtes de paquet COMPRESSED_NON_TCP, COMPRESSED_UDP et COMPRESSED_RTP.

Valeur suggérée : 15

NON_TCP_SPACE doit être au moins de 0 et au plus de 65  535 (la valeur 0 implique d’avoir un contexte).

F_MAX_PERIOD
Intervalle maximum entre les en-têtes pleins. Pas plus d’un en-tête F_MAX_PERIOD COMPRESSED_NON_TCP ne peut être envoyé entre des en-têtes FULL_HEADER.

Valeur suggérée : 256

Une valeur de zéro implique l’infini, c’est-à-dire qu’il n’y a pas de limite au nombre d’en-têtes COMPRESSED_NON_TCP consécutifs.

F_MAX_TIME
Intervalle de temps maximum entre des en-têtes pleins. Les en-têtes COMPRESSED_NON_TCP ne peuvent pas être envoyés plus de F_MAX_TIME secondes après l’envoi du dernier en-tête FULL_HEADER.

Valeur suggérée : 5 secondes

Une valeur de zéro implique l’infini.

MAX_HEADER
Plus grande taille, en octets, qui puisse être compressée.

Valeur suggérée : 168 octets

La valeur de MAX_HEADER devrait être assez grande pour qu’au moins l’en-tête de couche réseau externe puisse être compressé. Pour augmenter l’efficacité de la compression, MAX_HEADER devrait être réglé à une valeur assez grande pour couvrir les combinaisons courantes d’en-têtes de couche réseau et transport.

sous options
Le champ sous options consiste en zéro, une ou plusieurs sous options. Chaque sous option consiste en un champ type, un champ longueur et zéro, un ou plusieurs octets de paramètres, comme défini par le type de sous option. La valeur du champ longueur indique la longueur de la sous option dans son intégralité, y compris les longueur des champs type et longueur.

0	1	2	
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	
Type	Longueur	Paramètres...	

2.2	Sous option RTP-Compression

La sous option RTP-Compression est incluse dans l’option NCP IP-Compression-Protocol pour IPHC si la compression IP/UDP/RTP est à activer.

L’inclusion de la sous option RTP-Compression active l’utilisation des identifiants de protocole supplémentaires COMPRESSED_RTP et COMPRESSED_UDP avec les formes additionnelles de CONTEXT_STATE comme spécifié dans la [RFC2508].

Description

Active l’utilisation des identifiants de protocole COMPRESSED_RTP, COMPRESSED_UDP et CONTEXT_STATE comme spécifié dans la [RFC2508].

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

Type : 1

Longueur : 2

2.3	Sous option RTP-Compression améliorée

Une nouvelle sous option 2 est ajoutée pour utiliser la compression d’en-tête RTP améliorée définie dans la [RFC3545]. La sous option 2 est négociée à la place de la sous option 1 et ne s’ajoute pas à elle.

Description
Active l’utilisation des identifiants de protocole COMPRESSED_RTP et CONTEXT_STATE comme spécifié dans la [RFC2508]. De plus, elle active l’utilisation de la compression conforme à la [RFC3545] y compris l’utilisation de l’identifiant de protocole COMPRESSED_UDP avec des fanions supplémentaires et l’utilisation du fanion C avec l’identifiant de protocole FULL_HEADER pour indiquer l’utilisation de HDRCKSUM avec les paquets COMPRESSED_RTP et COMPRESSED_UDP.

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

Type : 2

Longueur : 2

2.4	Négociation de la compression d’en-tête pour les paquets seulement TCP ou seulement non-TCP

Dans la RFC 2509, il n’était pas possible de négocier la compression d’en-tête seulement TCP ou seulement non TCP parce qu’une valeur de 0 dans le champ TCP_SPACE ou le champ NON_TCP_SPACE signifie en fait que le contexte 1 est négocié.

Une nouvelle sous option 3 est ajoutée pour permettre de spécifier que le nombre de contextes pour TCP_SPACE ou NON_TCP_SPACE est zéro, désactivant l’utilisation de la compression correspondante.

Description

Active la compression d’en-tête pour les paquets seulement TCP ou seulement non TCP.

0	1	2	
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	
Type	Longueur	Paramètres...	

Type : 3

Longueur : 3

Paramètre
Le paramètre est 1 octet avec une des valeurs suivantes :

1 = le nombre de contextes pour TCP_SPACE est 0
2 = le nombre de contextes pour NON_TCP_SPACE est 0

Cette sous option se substitue aux valeurs qui étaient précédemment allouées à TCP_SPACE et NON_TCP_SPACE dans l’option de compression d’en-tête IP.

Si la sous option 3 est incluse plusieurs fois avec les paramètres 1 et 2, la compression est désactivée pour tous les paquets.

3	Protocoles de commande de réseau multiples

Le protocole IPHC est capable de compresser des datagrammes IPv6 et IPv4. IPCP et IPV6CP sont tous deux capables de négocier les valeurs de paramètre d’option pour IPHC. Ces valeurs s’appliquent à la compression des paquets où l’en-tête externe est respectivement un en-tête IPv4 et un en-tête IPv6.

3.1	Partage de l’espace d’identifiant de contexte

Pour la compression et la décompression des en-têtes de datagramme IPv4 et IPv6, l’espace d’identifiant de contexte est partagé. Alors que les valeurs de paramètre sont négociées indépendamment, le partage de l’espace d’identifiant de contexte devient plus complexe lorsque les valeurs de paramètre diffèrent. Comme les paquets compressés partagent l’espace d’identifiant de contexte, le moteur de compression doit allouer des identifiants de contexte à partir d’une base commune ; pour les paquets compressés, le décompresseur doit examiner létat du contexte pour détermine quels paramètres utiliser pour la décompression. Les espaces d’identifiant de contexte ne sont pas partagés entre TCP et non TCP/UDP/RTP. Le faire exigerait des mécanismes supplémentaires pour s’assurer qu’aucune erreur ne peut survenir lors du passage de l’utilisation d’un identifiant de contexte TCP à non-TCP.

4	Démultiplexage des datagrammes

La spécification IPHC [RFC2507] définit quatre formats d’en-tête pour les différents types d’en-têtes compressés. Ce sont  : TCP compressé, TCP compressé sans codage différentiel, non TCP compressé avec CID de 8 bits et non TCP compressé avec CID de 16 bits. Les deux formats non TCP peuvent être distingués par leur contenu de sorte que tous deux peuvent utiliser le même identifiant de couche de liaison. Un cinquième format d’en-tête, l’en-tête plein est distinct de l’en-tête régulier en ce qu’il porte des informations supplémentaires pour établir un contexte partagé entre le compresseur et le décompresseur.

La spécification de la compression d’en-tête IP/UDP/RTP [RFC2508] définit quatre formats supplémentaires d’en-têtes compressés. Ils sont pour UDP compressé et RTP compressé (par dessus UDP), tous deux avec des CID de 8 ou 16  bits. De plus, il y a un message d’erreur explicite du décompresseur au compresseur.

La couche de liaison doit être capable d’indiquer ces formats d’en-tête avec des valeurs distinctes. Neuf valeurs de champ de protocole de couche de liaison de données PPP sont spécifiées ci-dessous.

FULL_HEADER
La trame contient un en-tête plein comme spécifié dans la [RFC2508] au paragraphe 3.3.1. C’est le même que le FULL_HEADER spécifié dans la [RFC2507] au paragraphe 5.3.
Valeur : 0061 (hex)

COMPRESSED_TCP
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2507] au paragraphe 6a.
Valeur : 0063 (hex)

COMPRESSED_TCP_NODELTA
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2507] au paragraphe 6b.
Valeur : 2063 (hex)

COMPRESSED_NON_TCP
La trame contient un datagramme avec un en-tête compressé au format spécifié au paragraphe 6c ou au paragraphe 6d de la [RFC2507].
Valeur : 0065 (hex)

COMPRESSED_RTP_8
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2508] au paragraphe 3.3.2, utilisant des CID de 8 bits.
Valeur : 0069 (hex)

COMPRESSED_RTP_16
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2508] au paragraphe 3.3.2, utilisant des CID de 16 bits.
Valeur : 2069 (hex)

COMPRESSED_UDP_8
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2508] au paragraphe 3.3.3 ou comme spécifié dans la [RFC3545] au paragraphe 2.1, utilisant des CID de 8 bits.
Valeur : 0067 (hex)

COMPRESSED_UDP_16
La trame contient un datagramme avec un en-tête compressé au format spécifié dans la [RFC2508] au paragraphe 3.3.3 ou comme spécifié dans la [RFC3545] au paragraphe 2.1, utilisant des CID de 16 bits.
Valeur : 2067 (hex)

CONTEXT_STATE
La trame est un message de niveau liaison envoyé du décompresseur au compresseur comme spécifié dans la [RFC2508] au paragraphe 3.3.5.
Valeur : 2065 (hex)

5	Changements depuis la RFC 2509

Deux nouvelles sous options sont spécifiées. Voir les paragraphes 2.3 et 2.4.

6	Références
6.1	Références normatives

[RFC1144]	Jacobson, V., "Compression des en-têtes TCP/IP pour liaisons en série à basse vitesse", février 1990.

[RFC1332]	McGregor, G., "Le protocole PPP de commande du protocole Internet (IPCP)", RFC 1332, mai 1992.

[RFC2472]	Haskin, D. et E. Allen, "IP Version 6 sur PPP", RFC 2472, décembre 1998.

[RFC2507]	Degermark, M., Nordgren, B. et S. Pink, "Compression d’en-tête pour IP", RFC 2507, février 1999.

[RFC2508]	Casner, S. et V. Jacobson, "Compression des en-têtes IP/UDP/RTP pour liaisons en série à basse vitesse", RFC 2508, février 1999.

[RFC3241]	Bormann, C., "Compression d’en-tête robuste (ROHC) sur PPP", RFC 3241, avril 2002.

[RFC3545]	Koren, T., Casner, S., Geevarghese, J., Thompson, B. et P. Ruddy, "RTP compressé amélioré (CRTP) pour liaisons avec fort retard, perte de paquet et réordonnancement", RFC 3545, juillet 2003.

6.2	Références informatives

[RFC1661]	Simpson, W., Ed., "Protocole point à point (PPP)", STD 51, RFC 1661, juillet 1994.

[RFC2434]	Narten, T. et H. Alvestrand, "Lignes directrices pour l’écriture de la section Considérations relatives à l’IANA dans les RFC", BCP 26, RFC 2434, octobre 1998.

[RFC2686]	Bormann, C., "L’extension multi classe à PPP multi liaison", RFC 2686, septembre 1999.

[RFC3550]	Schulzrinne, H., Casner, S., Frederick, R. et V. Jacobson, "RTP : Protocole de transport pour applications en temps réel", RFC 3550, juillet 2003.

7	Considérations relatives à l’IANA

Le présent document ne requiert pas d’allocations supplémentaires pour les espaces de nom existants dans le registre des allocations de champ de protocole point à point de l’IANA. Cependant, trois espaces de noms ont été définis par les RFC 1332, RFC 2472, et RFC 2509 mais non créés dans le registre. Ces trois espaces de nom, décrits ci-dessous, ont été ajoutés au registre PPP. Le présent document spécifie deux allocations supplémentaires dans le troisième.

Le paragraphe 3.2 de la RFC 1332 spécifie une option de configuration IP-Compression-Protocol pour le protocole de commande IP PPP et définit une valeur pour le champ de type IP-Compression-Protocol dans cette option. Un registre IANA a été créé pour allouer des valeurs supplémentaires pour de champ de type. Comme établi dans la RFC 1332, les valeurs pour le champ type IP-Compression-Protocol sont touijours les mêmes que numéro de protocole (principal) PPP DLL alloué aux paquets du protocole de compression particulier. L’allocation de valeurs de type IP-Compression-Protocol supplémentaire est soumise à la procédure d’acceptation de l’IETF comme spécifié dans la [RFC2434].

Le paragraphe 4.2 de la RFC 2472 spécifie une option de configuration IPv6-Compression-Protocol pour le protocole de commande PPP IPv6 et définit une valeur pour le champ type IPv6-Compression-Protocol dans cette option. Un registre IANA a été créé pour allouer des valeurs supplémentaires pour ce champ type. L’option de configuration IPv6-Compression-Protocol a la même structure que l’option de configuration IP-Compression-Protocol définie dans la RFC  1332, mais l’ensemble des valeurs définies pour le champ type peut être différent. Comme établi dans la RFC  2472, les valeurs pour le champ type IPv6-Compression-Protocol sont toujours les mêmes que le numéro de protocole (principal) PPP DLL alloué aux paquets du protocole de compression particulier. L’allocation de valeurs de type IPv6-Compression-Protocol supplémentaires est soumise à la procédure d’acceptation de l’IETF comme spécifié dans la [RFC2434].

Le paragraphe 2.1 de la RFC 2509 spécifie une valeur de type supplémentaire à enregistrer à la fois pour l’option de configuration IP-Compression-Protocol et l’option de configuration IPv6-Compression-Protocol pour indiquer l’utilisation du protocole "Compression d’en-tête IP". La spécification de cette valeur de type est répétée au paragraphe 2.1 du présent document qui rend obsolète la RFC 2509. En conjonction avec la valeur de type supplémentairel, le format de l’option longueur variable est spécifié. Le format inclut un champ sous option qui peut contenir une ou plusieurs sous options. Chaque sous option commence par une valeur de type de sous option. Un registre IANA a été créé pour les valeurs de type de sous option ; il est intitulé "Types de sous options d’option de configuration de compression d’en-tête IP" (IP Header Compression Configuration Option Suboption Types).

Le paragraphe 2.2 de la RFC 2509 (et le présent document) définit un type de sous option. Les paragraphes 2.3 et 2.4 du présent document définissent deux types de sous option supplémentaires. On s’attend à ce que le nombre de sous options supplémentaires qu’il sera nécessaire de définir soit petit. Donc, toute personne souhaitant définir de nouvelles sous options devra produire une révision du présent document selon le processus normal des normes de l’Internet, comme spécifié dans la [RFC2434].

La RFC 2509 définit aussi neuf valeurs de champ de protocole de couche de liaison des données PPP dont la liste figure déjà dans le registre IANA des allocations de champ de protocole point à point. Le paragraphe 4 du présent document répète la spécification de ces valeurs sans changement.

8	Considérations sur la sécurité

La négociation de l’option définie ici n’impose pas de considération supplémentaires sur la sécurité au de là de celles qui s’appliquent autrement à PPP [RFC1661].

L’utilisation de la compression d’en-tête peut, dans des cas rares, causer une mauvaise livraison de paquets. Si nécessaire, la confidentialité di contenu des paquet devrait être assurée par chiffrement.

Le chiffrement appliqué à la couche IP (par exemple, en utilisant les mécanismes IPSEC) empêche la compression d’en-tête des en-têtes chiffrés, bien que la compression de l’en-tête IP externe et des en-têtes d’authentification/sécurité soit toujours possible comme décrit dans la [RFC2507]. Pour les paquets RTP, la compression des en-têtes pleins est possible si la charge utile RTP est chiffrée par elle-même sans chiffrement des en-têtes UDP ou RTP, comme décrit dans la [RFC3550]. Cette méthode est appropriée lorsque les informations d’en-tête UDP et RTP n’ont pas besoin d’être confidentielles.

9	Notice de droits de propriété intellectuelle

L’IETF ne prend pas position sur la validité ou la portée de droits de propriété intellectuelle ou autres droits qui pourraient être revendiqués comme appartenant à la mise en oeuvre 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 non disponible  ; aucun effort n’a d’ailleurs été effectué pour identifier de tels droits. Les informations sur les procédures de l’IETF par rapport aux droits dans les documents en cours de normalisation ou normalisés se trouvent dans le BCP-11. Des copies des revendications de droits disponibles pour publication et toute assurance de licence disponible, ou le résultat de tentatives d’obtention de licence générale ou permission d’utilisation de tels droits de propriété par les développeurs ou utilisateurs de la présente spécification peuvent être obtenues au secrétariat de l’IETF.

L’IETF invite toute partie intéressée à attirer son attention sur tous droits de propriété, patentes ou applications de patentes, ou autres droits de propriété qui pourraient couvrir la technologie qui pourrait être nécessaire pour mettre la présente norme en pratique. Prière d’adresser les informations au Directeur exécutif de l’IETF.

10	Remerciements

Mathias Engan a été le principal auteur de la RFC 2509, dont le présent document est une révision.

11	Adresse des auteurs

Tmima Koren	Stephen L. Casner	Carsten Bormann	
Cisco Systems, Inc.	Packet Design	Universitaet Bremen FB3 TZI	
170 West Tasman Drive	3400 Hillview Avenue, Building 3	Postfach 330440	
San Jose, CA 95134-1706	Palo Alto, CA 94304	D-28334 Bremen, GERMANY	
United States	United States	tél : +49.421.218-7024	
		fax : +49.421.218-7000	
mél : tmima@cisco.com	mél : casner@packetdesign.com 	mél : cabo@tzi.org 	

12	Déclaration de copyright

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes les copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations qu’il contient sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI ENCLOSES NE VIOLE AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Le financement de la fonction d’édition des RFC est actuellement fourni par Internet Society.