Lignes directrices pour les allocations par l'IANA des valeurs du protocole Internet et des en-têtes qui s'y rapportent

Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

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

Résumé

Le présent mémoire donne des lignes directrices à l'IANA pour l'allocation des paramètres des champs des en-têtes des protocoles IPv4, IPv6, ICMP, UDP et TCP.

1.   Introduction

Pendant de nombreuses années l'autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) (www.iana.org) a alloué les valeurs des paramètres pour les champs des protocoles qui ont été créés ou maintenus par l'équipe d'ingénierie de l'Internet (IETF, Internet Engineering Task Force). Lancée il y a quelques années, l'IETF a commencé à fournir à l'IANA les lignes directrices de l'allocation des paramètres pour des champs dans des nouveaux développements de protocoles. Malheureusement, ce type de lignes directrices n'était pas fourni de façon cohérente pour les champs des protocoles développés avant 1998. Le présent mémoire essaye de codifier les pratiques existantes de l'IANA utilisées pour l'allocation des paramètres dans le cas spécifique de certains de ces protocoles. Il est prévu que d'autres mémoires seront développés à l'avenir pour codifier les pratiques existantes dans les autres cas.

Le présent mémoire vise les champs dans les en-têtes de protocole IPv4, IPv6, ICMP, UDP et TCP pour lesquels l'IANA alloue les valeurs.

Les termes "Spécification exigée", "Révision par expert", "Approbation de l'IESG", "Consensus de l'IETF", et "Action de normalisation", sont utilisés dans le présent mémoire en référence aux processus décrits dans la [RFC2434].

2.   Allocations temporaires

De temps en temps, des allocations temporaires de valeurs sont faites pour des champs de ces en-têtes à utiliser pour des expériences. L'approbation de l'IESG est exigée pour de telles allocations temporaires.

3.   Champ Version dans l'en-tête IP

Le premier champ de l'en-tête IP de toutes les versions en cours de IP est le champ Version. De nouvelles valeurs dans le champ Version définissent de nouvelles versions du protocole IP et ne sont allouées qu'après une action de normalisation de l'IETF. On devrait noter que certains des bits du numéro de version sont utilisés par des schémas de compression d'en-tête TCP/IP. Précisément le bit de plus fort poids du champ Version est aussi utilisé par la compression d'en-tête TCP/IP [RFC1144], alors que les trois bits de plus fort poids sont utilisés par la compression d'en-tête IP [RFC2507].

4.   Considérations de l'IANA pour les champs dans l'en-tête IPv4

L'en-tête IPv4 [RFC0791] contient les champs suivants qui portent les valeurs allouées par l'IANA : Version, Type de service, Protocole, Adresse de source, Adresse de destination, et Type d'option.

4.1   Champ IPv4 Version IP

Le champ IPv4 Version est toujours 4.

4.2   Champ IPv4 Type de service

Le champ Type de service décrit dans la [RFC0791] a été supplanté dans la [RFC2474] par le champ de 6 bits Services différenciés (DS) et un champ de 2 bits qui est actuellement réservé. L'IANA alloue les valeurs dans le champ DS en suivant la section Considérations relatives à l'IANA de la [RFC2474]. La [RFC2481] décrit une utilisation expérimentale du champ de 2 bits "actuellement inutilisé". D'autres utilisations expérimentales de ce champ peuvent être allouées après le processus d'approbation de l'IESG. Des valeurs permanentes dans ce champ sont allouées suivant un processus d'action de normalisation.

4.3   Champ IPv4 Protocole

L'IANA alloue des valeurs tirées de l'espace de noms Protocole IPv4 suivant un processus de révision par expert, d'approbation de l'IESG ou d'action de normalisation. Le processus de révision par expert ne devrait être utilisé que dans les cas particuliers où est impliquée la non divulgation d'informations. Dans ces cas, le ou les experts devraient être désignés par l'IESG.

4.4   Champs IPv4 Adresse de source et Adresse de destination

Les adresses IPv4 de source et de destination utilisent le même espace de noms mais n'utilisent pas nécessairement les mêmes valeurs. Les valeurs dans ces champs entrent dans un certain nombre de gammes définies dans la [RFC0791] et dans la [RFC0988].

4.4.1   Adresses IPv4 d'envoi individuel

La corporation pour l'allocation des noms et des numéros de l'Internet (ICANN, Internet Corporation for Assigned Names and Numbers) a récemment accepté la responsabilité de la formulation de lignes directrices spécifiques pour l'allocation des valeurs de l'espace d'adresses d'envoi individuel IPv4 (valeurs de 0.0.0.0 à 223.255.255.255 ) autres que les valeurs des gammes 0/8 (qui était réservée dans [AN80]) et 127/8 (d'où l'adresse de bouclage a été tirée) ainsi que les autres valeurs déjà allouées par l'IETF pour des fonctions ou objets particuliers. (Par exemple, les adresses privées définies dans la RFC 1918.) Les futures allocations dans les gammes 0/8 et 127/8 exigent un processus d'action de normalisation car les mises en œuvre IP actuelles pourraient être touchées par ces allocations.

4.4.2   Adresses IPv4 de diffusion groupée

Les adresses IPv4 qui entrent dans la gamme de 224.0.0.0 à 239.255.255.255 sont connues comme adresses de diffusion groupée. L'IETF a alloué par ses processus normaux un certain nombre d'adresses IPv4 de diffusion groupée pour des besoins particuliers. Par exemple, [ADSCP] a alloué un numéro d'adresse de diffusion groupée IPv4 pour correspondre aux adresses de diffusion groupée à portée limitée de IPv6. Aussi, les valeurs dans la gamme de 224.0.0.0 à 224.0.0.255, inclus, sont réservés par l'IANA pour l'utilisation des protocoles d'acheminement et de découverte de topologie de bas niveau ou pour les protocoles de maintenance, tels que de découverte de passerelles et de rapports d'adhésion à un groupe. (Voir la page d'accueil du site de la Toile de l'IANA) De nouvelles valeurs dans cette gamme sont allouées suivant un processus d'approbation par l'IESG ou d'action de normalisation. Les allocations d'adresse de diffusion groupée individuelles se font selon une révision par expert, approbation de l'IESG ou action de normalisation. Jusqu'à ce que des travaux complémentaires soient menés à leur terme sur les protocoles de diffusion groupée, les allocations à grande échelle d'adresses IPv4 de diffusion groupée n'est pas recommandée.

De temps en temps, il y a des demandes pour une allocation temporaire d'espace de diffusion groupée pour des besoins expérimentaux. Elles débouchent sur un processus d'approbation par l'IESG et devraient être d'une durée limitée, à un an par exemple.

4.4.3   Adresses IPv4 réservées

Les adresses IPv4 dans a gamme de 240.0.0.0 à 255.255.255.254 sont réservées [AN81], [MULT] et les mises en œuvre IPv4 conformes élimineront tout paquet qui les utilise. Les adresses dans cette gamme ne doivent pas être allouées tant qu'une action de normalisation de l'IETF n'aura pas modifié le protocole IPv4 de façon à rendre ces adresses valides. L'adresse 255.255.255.255 est l'adresse de diffusion limitée.

4.5   Champ IPv4 Type d'option

L'IANA alloue des valeurs de l'espace de nom de type d'option IPv4 à la suite d'une approbation de l'IESG, du consensus de l'IETF ou d'un processus d'action de normalisation.

5.   Considérations de l'IANA pour les champs dans l'en-tête IPv6

L'en-tête IPv6 [V6] contient les champs suivants qui portent les valeurs allouées dans les espaces de noms gérés par l'IANA : Version (par définition toujours 6 dans IPv6), Classe de trafic, Prochain en-tête, Adresse de source et Adresse de destination. De plus, les en-têtes d'extension des options IPv6 Bond par bond et Destination comportent un champ Type d'option avec des valeurs allouées dans un espace de noms géré par l'IANA.

5.1   Champ IPv6 Version

Le champ Version IPv6 est toujours 6.

5.2   Champ IPv6 Classe de trafic

Le champ Classe de trafic IPv6 est décrit dans la [RFC2474] comme un champ de 6 bits de services différenciés (DS) et un champ de 2 bits qui est actuellement réservé. Voir au paragraphe 4.2 les lignes directrices pour l'allocation de ces champs.

5.3   Champ IPv6 Prochain en-tête

Le champ IPv6 Prochain en-tête porte des valeurs provenant du même espace de noms que celui de Protocole IPv4. Ces valeurs sont allouées comme exposé au paragraphe 4.3.

5.4   Champ IPv6 Adresses de source et de destination en envoi individuel

Les champs IPv6 Adresse de source et de Adresse de destination utilisent tous deux les mêmes valeurs et sont décrits dans [V6AD]. Les adresses sont divisées en gammes définies par un préfixe de format (FP, Format Prefix) de longueur variable.

5.4.1   Adresses IPv6 en envoi individuel à agrégation mondiale

L'IANA a été chargée de tout l'espace d'adresse IPv6 par l'IAB dans [V6AA].Récemment, l'IANA a accepté des lignes directrices spécifiques pour l'allocation des valeurs dans le préfixe de format des adresses d'envoi individuel à agrégation mondiale (FP 001) formulées par les registres régionaux de l'Internet.

5.4.2   Adresses IPv6 à la cantonade

Les adresses IPv6 d'envoi à la cantonade sont définies dans [V6AD]. Les adresses d'envoi à la cantonade sont allouées à partir de l'espace d'adresses d'envoi individuel et les adresses d'envoi à la cantonade sont syntaxiquement indistinguables des adresses d'envoi individuel. Les allocations des adresses IPv6 de sous-réseau d'envoi à la cantonade suivent le processus décrit dans [V6AD]. L'allocation des autres adresses IPv6 d'envoi à la cantonade suit le processus utilisé pour les adresses IPv6 en envoi individuel agrégeables mondialement, (paragraphe 5.4.1).

5.4.3   Adresses IPv6 de diffusion groupée

Les adresses IPv6 de diffusion groupée sont définies dans [V6AD]. Elles sont identifiées par un FP de 0xFF. Les lignes directrices pour l'allocation des adresses IPv6 de diffusion groupée sont décrites dans [MASGN].

5.4.4   Préfixes de format IPv6 Non alloués et Réservés

La responsabilité de l'allocation des valeurs dans chacun des préfixes de format "non alloués" et "réservés" est déléguée par approbation de l'IESG ou processus d'action de normalisation car les règles pour le traitement de ces préfixes de format n'ont pas été définies dans les mises en œuvre de IPv6.

5.5   Champs d'option IPv6 Bond par bond et Destination

Les valeurs pour les champs des options IPv6 Bond par bond et Destination sont allouées en utilisant un processus d'approbation de l'IESG, de consensus de l'IETF, ou d'action de normalisation.

5.6   Champs IPv6 Découverte de voisin

L'en-tête IPv6 Découverte de voisin [NDV6] contient les champs suivants qui portent les valeurs allouées à partir des espaces de noms gérés par l'IANA : Type, Code et Type d'option.

Les valeurs pour les champs IPv6 Découverte de voisin Type, Code, et Type d'option sont allouées en utilisant un processus d'approbation par l'IESG ou d'action de normalisation.

6.   Considérations de l'IANA sur les champs dans l'en-tête ICMP IPv4

L'en-tête ICMP IPv4 [ICMP] contient les champs suivants qui portent les valeurs allouées à partir des espaces de noms gérés par l'IANA : Type et Code. Les valeurs du champ Code sont définies par rapport à une valeur de Type spécifique.

Les valeurs pour les champs ICMP IPv4 sont allouées en utilisant les processus d'approbation de l'IESG ou d'action de normalisation. Les valeurs de Code pour les champs Type ICMP Ipv4 existants sont allouées en utilisant les processus d'approbation de l'IESG ou d'action de normalisation. La politique pour l'allocation des valeurs de Code pour les nouveaux Types ICMP IPv4 devraient être définie dans le document qui définit la valeur du nouveau Type.

7.   Considérations de l'IANA sur les champs dans l'en-tête ICMP IPv6

L'en-tête ICMP IPv6 [ICMPV6] contient les champs suivants qui portent les valeurs allouées à partir des espaces de noms gérés par l' IANA : Type et Code. Les valeurs du champ Code sont définies par rapport à une valeur de Type spécifique.

Les valeurs pour les champs ICMP IPv6 Type sont allouées en utilisant les processus d'approbation par l'IESG ou d'action de normalisation. Les valeurs de Code pour les champs existants de Type ICMP IPv6 sont allouées en utilisant les processus d'approbation par l'IESG ou d'action de normalisation. La politique d'allocation des valeurs de Code pour les nouveaux types ICMP IPv6 devrait être définie dans le document qui définit la valeur du nouveau type.

8.   Considérations de l'IANA sur les champs dans l'en-tête UDP

L'en-tête UDP [UDP] contient les champs suivants qui portent des valeurs allouées à partir des espaces de noms gérés par l'IANA : Accès de source et Accès de destination.

Les champs Accès de source et Accès de destination utilisent tous deux le même espace de noms. Les valeurs dans cet espace de noms sont allouées suivant un processus de spécification exigée, revue d'expert, approbation de l'IESG, consensus de l'IETF, ou d'action de normalisation. Noter que certaines allocations peuvent impliquer des informations à ne pas divulguer.

9.   Considérations de l'IANA sur les champs dans l'en-tête TCP

L'en-tête TCP [TCP] contient les champs suivants qui portent des valeurs allouées à partir des espaces de noms gérés par l'IANA : Accès de source et Accès de destination, Bits réservés, et Type d'option.

9.1   Champs TCP Accès de source et Accès de destination

Les champs Accès de Source et Accès de destination utilisent tous deux le même espace de noms. Les valeurs dans cet espace de noms sont allouées suivants les processus de spécification exigée, de revue par expert, d'approbation par l'IESG, de consensus de l'IETF, ou d'action de normalisation. Noter que certaines allocations peuvent impliquer des informations à ne pas divulguer.

9.2   Bits réservés dans l'en-tête TCP

Les bits "Réservé" dans l'en-tête TCP sont alloués suivant un processus d'action de normalisation.

9.3   Champ Type d'option TCP

Les valeurs dans le champ Type d'option sont allouées suivant un processus d'approbation de l'IESG ou d'action de normalisation.

10.   Considérations pour la sécurité

Les analyseurs de sécurité tels que les pare-feu et les surveillants de détection d'intrusion dans le réseau s'appuient souvent sur des interprétations non ambiguës des champs décrits dans le présent mémoire. Lorsque sont allouées de nouvelles valeurs pour les champs, les analyseurs de sécurité existants qui ne comprennent pas ces nouvelles valeurs peuvent échouer, ce qui résulte en la perte de la connexité si l'analyseur refuse de transmettre le trafic non reconnu, ou en la perte de la sécurité si il transmet le trafic et que les nouvelles valeurs sont utilisées au titre d'une attaque. Cette vulnérabilité plaide en faveur d'une forte visibilité (qu'assurent les processus d'action de normalisation et de consensus de l'IETF) pour les allocations chaque fois que possible.

11.   Références

[ADSCP]   D. Meyer, "Diffusion groupée sur IP limitée administrativement", RFC2365, juillet 1998. (BCP0023)

[AN80]   J. Postel, "Numéros alloués", RFC758, août 1979.

[AN81]   J. Postel, "Numéros alloués", RFC 790, septembre 1981.

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

[RFC2474]   K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ parRFC3168, RFC3260) (P.S.)

[RFC2481]   K. Ramakrishnan, S. Floyd, "Proposition d'ajout de la notification d'encombrement explicite (ECN) à IP", janvier 1999.

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

[ICMP]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", RFC0792, STD 5, septembre 1981.

[ICMPV6]   A. Conta, S. Deering, "Protocole de message de contrôle Internet (ICMPv6) pour le protocole Internet version 6 (IPv6)", RFC2463, décembre 1998. (Obsolète, voirRFC4443) (D.S.)

[RFC2507]   M. Degermark, B. Nordgren, S. Pink, "Compression d'en-tête IP", février 1999. (P.S.)

[MASGN]   R. Hinden, S. Deering, "Allocation des adresses de diffusion groupée IPv6", RFC2375, juillet 1998. (Info.)

[RFC0988]   S. Deering, "Extensions d’hôte pour la diffusion groupée IP", juillet 1986.(Obsolète, voir RFC1054/1112),

[NDV6]   T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", RFC2461, décembre 1998. (Obsolète, voirRFC4861) (D.S.)

[TCP]   J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", RFC0793, (STD 7), septembre 1981.

[UDP]   J. Postel, "Protocole de datagramme d’utilisateur", RFC0768, (STD 6), 28 août 1980.

[RFC0791]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[V6AA]   IAB, IESG, "Gestion de l'allocation des adresses IPv6", RFC1881, décembre 1995. (Information)

[V6AD]   R. Hinden, S. Deering, "Architecture d'adressage IP version 6", RFC2373, juillet 1998. (Obsolète, voirRFC3513) (P.S.)

12.   Adresse des auteurs

13.   Déclaration complète de droits de reproduction

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

Ce document et ses traductions 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 droits de reproduction 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 la notice de droits 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 droits de reproduction définis dans les processus des normes pour l'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, 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 assuré par la Internet Society.