Groupe de travail Réseau	B. Fenner, AT&T Labs - Research	
Request for Comments : 4727 	novembre 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Valeurs expérimentales dans les en-têtes 
IPv4, IPv6, ICMPv4, ICMPv6, UDP, et TCP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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 (2006). Tous droits réservés.

Résumé
Quand on expérimente ou on étend des protocoles, il est souvent nécessaire d'utiliser un numéro ou une constante de protocole afin de tester ou expérimenter en vrai la nouvelle fonction, même quand l'essai a lieu dans un environnement clos. Le présent document réserve certaines gammes de numéros à des fins d'expérimentation dans des protocoles spécifiques où le besoin de prise en charge d'expérimentations a été identifié, et il décrit les numéros qui ont déjà été réservés par d'autres documents.
Table des matières
1. Introduction	2
2. Champs dans l'en-tête IPv4	2
2.1 Champ Version IP dans l'en-tête IPv4	2
2.2 Champ Type de service IPv4	2
2.3 Champ Protocole IPv4	2
2.4 Adresses IPv4 de source et de destination	2
2.5 Champ Type d'option IPv4	2
3. Champs dans l'en-tête IPv6	3
3.1 Champ Version IP dans l'en-tête IPv6	3
3.2 Champ Classe de trafic IPv6	3
3.3 Champ Prochain en-tête IPv6	3
3.4 Adresses IPv6 de source et de destination	3
3.5 Champs d'option Bond par bond et Destination IPv6	3
3.6 Type d'acheminement d'en-tête Acheminement IPv6	3
4. Champs dans l'en-tête IPv4 ICMP	4
5. Champs dans l'en-tête IPv6 ICMP	4
5.1 Champs de découverte de voisin IPv6	4
6. Champs dans l'en-tête UDP	4
7. Champs dans l'en-tête TCP	4
7.1 Champs d'accès de source et destination TCP	4
7.2 Bits réservés dans l'en-tête TCP	4
7.3 Champ Type d'option TCP	4
8. Considérations relatives à l'IANA	4
9. Considérations sur la sécurité	6
10. Références	6
10.1 Références normatives	6
10.2 Référence pour information	7
Adresse de l'auteur	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

La [RFC3692] recommande d'allouer des numéros d'option pour les expérimentations et les essais. Le présent document documente plusieurs de ces allocations pour les espaces de numéros dont les considérations relatives à l'IANA sont documentées dans la [RFC2780]. Le présent document suit généralement la forme de la [RFC2780].

Quand on utilise ces valeurs, il faut examiner attentivement les avis de la Section 1 et du paragraphe 1.1 de la [RFC3692]. Il n'est pas approprié de simplement choisir une de ces valeurs et de la transposer dans un système.

Note : alors que la [RFC3692] dit qu'il peut n'être pas nécessaire d'allouer des valeurs pour les accès UDP et TCP, la Section 6 et le paragraphe 7.1 réservent explicitement les accès dans ce but pour éviter tout conflit possible.

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

 	2.1	Champ Version IP dans l'en-tête IPv4
Le champ Version dans les paquets IPv4 est toujours 4.

 	2.2	Champ Type de service IPv4
La [RFC2474] définit Pool 2 (tous les codets xxxx11, où 'x' se réfère à '0' ou '1') comme utilisation expérimentale/locale, de sorte qu'aucun codet supplémentaire ne devrait être nécessaire. Le champ Notification explicite d'encombrement (ECN, Explicit Congestion Notification) de la [RFC3168] n'a pas de codet libre à allouer.

 	2.3	Champ Protocole IPv4
La [RFC3692] alloue deux codets expérimentaux (253 et 254) pour le champ Protocole IPv4.

 	2.4	Adresses IPv4 de source et de destination
 	2.4.1	Envoi individuel IPv4
Aucune adresse expérimentale IPv4 n'est définie. Pour certaines expériences, les gammes d'adresses mises de côté pour les internets privés dans la [RFC1918] peuvent être utiles. Il n'est pas approprié d'utiliser d'autres adresses IPv4 dédiées à un usage particulier [RFC3330] pour des expérimentations.

Au moment de la rédaction du présent document, certains registraires Internet ont des politiques qui permettent des allocations expérimentales dans des espaces de nombres qu'ils contrôlent. Selon l'expérience, le registre, et leur politique, ce peut être un chemin approprié à suivre.

 	2.4.2	Diffusion groupée  IPv4
Le groupe acheminable mondialement 224.0.1.20 est mis de côté pour l'expérimentation. Pour certaines expériences, les groupes de diffusion groupée à portée administrativement limitée définis dans la [RFC2365] peuvent être utiles. Le présent document alloue un seul groupe à portée limité à la liaison locale, 224.0.0.254, et un seul groupe à portée relative, 254.

 	2.5	Champ Type d'option IPv4
Le présent document alloue un seul numéro d'option, avec toutes les valeurs définies des champs "copy" et "class", résultant en quatre codes de type d'option distincts. Voir à la Section 8 les valeurs allouées.

 	3.	Champs dans l'en-tête IPv6

L'en-tête IPv6 [RFC2460] contient les champs suivants qui portent les valeurs allouées dans les espaces de noms gérés par l'IANA : Version, Classe de trafic, Prochain en-tête, Adresse de source et de destination. De plus, les en-têtes d'extension Options bond par bond IPv6 et Options de destination incluent un champ Type d'option avec des valeurs allouées dans un espace de noms géré par l'IANA. L'en-tête Acheminement IPv6 contient un champ Type qui n'est actuellement pas une politique d'allocation explicite de l'IANA.

 	3.1	Champ Version IP dans l'en-tête IPv6
Le champ Version dans les paquets IPv6 est toujours 6.

 	3.2	Champ Classe de trafic IPv6
La [RFC2474] définit Pool 2 (tous les codets xxxx11, où 'x' se réfère à '0' ou '1') comme utilisation expérimentale/locale, de sorte qu'aucun codet supplémentaire ne devrait être nécessaire. Le champ ECN [RFC3168] n'a pas de codet libre à allouer.

 	3.3	Champ Prochain en-tête IPv6
La [RFC3692] alloue deux codets expérimentaux (253 et 254) pour le champ Prochain en-tête IPv6.

 	3.4	Adresses IPv6 de source et de destination
 	3.4.1	Adresses IPv6 d'envoi individuel
La [RFC2928] définit un ensemble d'adresses IPv6 pour les essais et les expériences :

Le bloc d'identifiants de sous-TLA alloué à l'IANA (c'est-à-dire, 2001:0000::/29 - 2001:01F8::/29) est pour l'allocation aux usages d'essai et d'expérimentation pour la prise en charge d'activités comme le 6bone, et pour de nouvelles approches comme les échanges.

Cependant, au moment de cette rédaction, il n'y a pas d'adresses IPv6 de  style RFC3692 expérimentales allouées. La [RFC4473] crée un registre IANA qui pourrait à l'avenir contenir de telles allocations. Pour certaines expériences, des adresses locales uniques [RFC4193] pourraient être utiles. Il n'est pas approprié d'utiliser de telles adresses dans le préfixe de documentation [RFC3849] pour l'expérimentation.

Au moment de cette rédaction, certains registraires Internet ont des politiques qui permettent des allocations expérimentales dans les espaces de nombres qu'ils contrôlent. Selon l'expérientce, le registre, et leur politique, ceci peut être un chemin approprié à suivre.

 	3.4.2	Adresses de diffusion groupée IPv6
Le groupe FF0X::114 est mis de côté pour l'expérimentation à tous les niveaux de portée. Les plus petites portées peuvent être particulièrement utiles pour l'expérimentation, car elles sont définies pour ne pas s'écarter de limites définies, ce qui peut être pris comme la limite de l'expérience. Pour certaines expériences, d'autres adresses de diffusion groupée avec le bit T (adresse non allouée en permanence ou "transitoire") [RFC4291] établi peuvent être utiles.

 	3.5	Champs d'option Bond par bond et Destination IPv6
Le présent document alloue un seul type d'option, avec toutes les valeurs possibles des champs "act" et "chg", résultant en huit codes de type d'option distincts. Voir les valeurs allouées à la Section 8.

 	3.6	Type d'acheminement d'en-tête Acheminement IPv6
Le présent document alloue deux valeurs pour le champ Type d'acheminement dans l'en-tête Acheminement IPv6, 253 et 254.

 	4.	Champs dans l'en-tête IPv4 ICMP

Le présent document alloue deux numéros de type ICMPv4, 253 et 254. Les valeurs de code ICMPv4 sont allouées par type, de sorte qu'il n'est pas faisable d'allouer des valeurs expérimentales dans le présent document.

 	5.	Champs dans l'en-tête IPv6 ICMP

La [RFC4443] inclut des valeurs de type ICMPv6 expérimentaux pour les types de message Information (200, 201) et Erreur (100, 101). Les valeurs de code ICMPv6 sont allouées par type, de sorte qu'il n'est pas faisable d'allouer des valeurs expérimentales dans le présent document.

 	5.1	Champs de découverte de voisin IPv6
L'en-tête Découverte de voisin IPv6 [RFC2461] contient les champs suivants qui portent les valeurs allouées dans l'espace de noms géré par l'IANA : Type, Code, et Type d'option.

 	5.1.1	Type de découverte de voisin IPv6
Le champ Type de découverte de voisin est le même que le champ Type ICMPv6. Voir ces codets à la Section 5.

 	5.1.2	Code de découverte de voisin IPv6
Le champ Code ICMPv6 n'est pas utilisé dans la découverte de voisin IPv6, de sorte qu'aucun codet expérimental n'est nécessaire.

 	5.1.3	Type d'option Découverte de voisin IPv6
Le présent document alloue deux types d'option Découverte de voisin IPv6, 253 et 254.

 	6.	Champs dans l'en-tête UDP

Deux accès systèmes, 1021 et 1022, ont été réservés pour l'expérimentation pour UDP et TCP.

 	7.	Champs dans l'en-tête TCP
 	7.1	Champs d'accès de source et destination TCP
Deux accès systèmes, 1021 et 1022, ont été réservés pour l'expérimentation pour UDP et TCP.

 	7.2	Bits réservés dans l'en-tête TCP
Il n'y a pas assez de bits réservés à allouer pour l'expérimentation.

 	7.3	Champ Type d'option TCP
Deux options TCP, 253 et 254, ont été réservées pour l'expérimentation avec les options TCP.

 	8.	Considérations relatives à l'IANA

Les nouvelles allocations sont résumées ci-dessous.

Adresses de diffusion groupée IPv4 (section adresses de diffusion groupée (224.0.0/24) de bloc de contrôle de réseau local) (paragraphe 2.4.2) :
Adresse de groupe	Nom
224.0.0.254	Expérience de style RFC3692 (*)

Adresses de diffusion groupée IPv4 (section adresses relatives aus adresses de diffusion groupée) (paragraphe 2.4.2) :
Relative	Description
254	Expérience de style RFC3692 (*)

Numéros d'option IPv4 (section paramètres IP initiaux) (paragraphe 2.5) :
Copie	Classe	Numéro	Valeur
    0	0	30	30
    0	2	30	94
    1	0	30	158
    1	2	30	222

Types d'option IPv6 (Section 5.b. Paramètres IPv6) (paragaphe 3.5) :
HEX	act	chg	rest
0x1e	00	0	11110
0x3e	00	1	11110
0x5e	01	0	11110
0x7e	01	1	11110
0x9e	10	0	11110
0xbe	10	1	11110
0xde	11	0	11110
0xfe	11	1	11110

Formats d'option Découverte de voisin IPv6 (paramètres icmpv6) (paragraphe 5.1.3) :
Type	Description
253	Expérience de style 1 RFC3692 (*)
254	Expérience de style 2 RFC3692 (*)

 	Types d'acheminement d'en-tête Acheminement IPv6 (paramètres IPv6, Section 5.c.) (paragraphe 3.6) :
Type	Description
253	Expérience de style 1 RFC3692 (*)
254 	Expérience de style 2 RFC3692 (*)

Numéros de type ICMPv4 (paramètres ICMP) (Section 4) :
Type	Nom
253	Expérience de style 1 RFC3692 (*)
254	Expérience de style 2 RFC3692 (*)

Numéros d'accès système (numéros d'accès) (Section 6 et paragraphe 7.1) :
Mot-clé	décimal	Description
exp1	1021/udp	Expérience de style 1 RFC3692 (*)
exp1	1021/tcp	Expérience de style 1 RFC3692 (*)
exp2	1022/udp	Expérience de style 2 RFC3692 (*)
exp2	1022/tcp	Expérience de style 2 RFC3692 (*)

Numéros d'option TCP (paramètres TCP) (paragraphe 7.3) :
Type	Longueur	Signification
253	N	Expérience de style 1 RFC3692 (*)
254	N	Expérience de style 2 RFC3692 (*)

Chacun de ces enregistrements est accompagné de la note de bas de page suivantte :

(*) Il est seulement approprié d'utiliser ces valeurs dans des expériences explicitement configurées ; elles NE DOIVENT PAS être prises comme valeurs par défaut dans les mises en œuvre. Voir les détails dans la RFC 3692.

 	9.	Considérations sur la sécurité

Les réseaux de production ne prennent pas nécessairement en charge l'utilisation de codets experimentaux dans les en-têtes IP. La portée de réseau de la prise en charge de valeurs expérimentales devrait être évaluée avec soin avant de déployer une expérience à travers des domaines de réseau étendus, comme l'Internet public. Le potentiel de perturbation du fonctionnement stable du réseau qui héberge l'expérience par l'utilisation de codets expérimentaux non pris en charge est une considération sérieuse quand on programme une expérience qui utilise de tels codets.

Les analyseurs de sécurité comme les pare-feu et les surveillants de détection d'intrusion dans les réseaux s'appuient souvent sur des interprétations non ambiguës des champs décrits dans le présent mémoire. Lorsque de nouvelles valeurs de champs sont allouées, les analyseurs de sécurité existants qui ne comprennent pas les nouvelles valeurs peuvent échouer, résultant en une perte de connexité, si l'analyseur refuse de transmettre le trafic non reconnu, ou en une perte de la sécurité si il transmet le trafic et si les nouvelles valeurs sont utilisées au titre d'une attaque. Allouer des valeurs connues pour les expériences peut permettre à ces analyseurs d'effectuer une action connue pour le trafic explicitement expérimental.

Parce que les options expérimentales IPv4 définies au paragraphe 2.5 ne sont pas incluses dans les calculs de IPsec AH [RFC4302], il n'est pas possible d'authentifier leur utilisation. Les auteurs d'expériences devrait y penser quand ils conçoivent leurs expériences. Les utilisateurs des options expérimentales IPv6 définies au paragraphe 3.5 peuvent choisir si l'option est ou non incluse dans les calculs de AH an choisissant la valeur du champ "chg".

Quand des codets expérimentaux sont déployés dans un domaine de réseau auto-contraint administrativement, l'administrateur de réseau devrait s'assurer que chaque codet est utilisé de façon cohérente pour éviter des interférences entre les expériences. Quand des codets expérimentaux sont utilisés dans du trafic qui franchit plusieurs domaines administratifs, les auteurs de l'expérience devrait supposer qu'il y a un risque que les mêmes codets soient utilisés simultanément par d'autres expériences et donc qu'il y a une possibilité que les expériences interfèrent. Une attention particulière devrait être apportée aux menaces sur la sécurité que de telles interférences pourraient créer.

 	10.	Références
 	10.1	Références normatives

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

[RFC1918]	Y. Rekhter et autres, "Allocation d'adresse pour les internets privés", BCP 5, février 1996.

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

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S ; Remplacée par RFC8200, STD 86)

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

[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. (P.S. ; MàJ par RFC3168, RFC3260, RFC8436)

[RFC2780]	S. Bradner et V. Paxson, "Lignes directrices pour les allocations par l'IANA des valeurs du protocole Internet et des en-têtes qui s'y rapportent", BCP 37, mars 2000.

[RFC2928]	R. Hinden et autres, "Allocations initiales d'identifiants sous-TLA IPv6", septembre 2000. (Information)

[RFC3168]	K. Ramakrishnan et autres, "Ajout de la notification explicite d'encombrement (ECN) à IP", septembre 2001. (P.S. ; MàJ par RFC8311)

[RFC3330]	IANA, "Adresses IPv4 d'usage particulier", septembre 2002. (Information) (Remplacée par RFC5735)

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

[RFC3849]	G. Huston, A. Lord, P. Smith "Préfixe d'adresse IPv6 réservé pour la documentation", juillet 2004. (Information)

[RFC4193]	R. Hinden, B. Haberman, "Adresses IPv6 en envoi individuel uniques localement", octobre 2005. (P.S.)

[RFC4291]	R. Hinden, S. Deering, "Architecture d'adressage IP version 6", février 2006. (MàJ par 5952 et 6052, 8064) (D.S.)

[RFC4302]	S. Kent, "En-tête d'authentification IP", décembre 2005. (P.S.)

[RFC4443]	A. Conta et autres, "Spécification du protocole de message de contrôle Internet (ICMPv6) pour la version 6 du protocole Internet (IPv6)", mars 2006. (Remplace RFC2463) (MàJ RFC2780) (MàJ par RFC4884) (D.S.)

 	10.2	Référence pour information

[RFC4773]	G. Huston, "Administration par l'IANA du bloc d'adresses IPv6 d'utilisation spéciale", décembre 2006. (Information ; remplacée par RFC6890)

 	Adresse de l'auteur

Bill Fenner
AT&T Labs - Research
75 Willow Rd
Menlo Park, CA  94025
USA
téléphone : +1 650 330-7893
mél : fenner@research.att.com 

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues 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, le IETF TRUST 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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 pourraient être revendiqués 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’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

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