Groupe de travail Réseau	J. Arkko, Ericsson	
Request for Comments: 5494	C. Pignataro, Cisco Systems	
Met à jour : 826, 951, 1044, 1329, 2131, 2132, 2176, 2225, 2834, 2835, 3315, 4338, 4361, 4701	avril 2009	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Lignes directrices de l'allocation par l'IANA du protocole de résolution d'adresse (ARP)

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le présent document spécifie les lignes directrices selon lesquelles l'IANA alloue de nouvelles valeurs dans le protocole de résolution d'adresse (ARP, Address Resolution Protocol). Ce document réserve aussi des numéros pour les besoins d'expérimentation. Les changements affectent aussi d'autres protocoles qui emploient des valeurs provenant de l'espace de noms ARP.
Table des matières
1. Introduction	1
2. Considérations relatives à l'IANA 	2
3. Allocations définies dans le présent document	2
4. Considérations sur la sécurité	3
5. Remerciements	3
6. Références	3
6.1 Références normatives	3
6.2 Références pour information	4
Appendice A. Changements aux RFC originales	4
Adresse des auteurs	4

 	1.	Introduction

Le présent document spécifie les lignes directrices pour l'allocation par l'IANA [RFC5226] de nouvelles valeurs pour divers champs dans le protocole de résolution d'adresse (ARP, Address Resolution Protocol) [RFC0826]. Le changement est aussi applicable aux extensions d'ARP qui utilisent le même format de message, comme les [RFC0903], [RFC1931], et [RFC2390].

Le changement affecte aussi d'autres protocoles qui emploient des valeurs provenant de l'espace de noms d'ARP. Par exemple, l'espace de numéros de type d'adresse de matériel ARP (ar$hrd) est aussi utilisé dans les champs "htype" (type d'adresse de matériel) dans le protocole Bootstrap (BOOTP) [RFC0951] et dans le protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) [RFC2131], ainsi que dans le champ "type de matériel" dans les identifiants DHCP uniques de DHCPv6 [RFC3315]. Ces protocoles sont donc affectés par la mise à jour des règles de l'IANA. Les autres spécifications affectées incluent les mécanismes spécialisé de résolution d'adresse dans :

o  HYPERchannel [RFC1044]

o  Options DHCP [RFC2132], [RFC4361]

o  ARP en mode de transfert asynchrone (ATM, Asynchronous Transfer Mode) [RFC2225]

o  ARP à interface parallèle hautes performances (HARP, High-Performance Parallel Interface ARP) [RFC2834], [RFC2835]

o  ARP à interface de données distribuées par fibre (FDDI, Fiber Distributed Data Interface) par commande d'accès au support (MAC, Media Access Control) double [RFC1329]

o  ARP sur MAPOS (Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy) [RFC2176]

o  ARP sur canal fibre (FC, Fibre Channel) [RFC4338]

o  Enregistrement de ressource DHCID du DNS [RFC4701]

Les lignes directrices à l'IANA sont données dans la Section 2. Aucune ligne directrice pour l'IANA n'existait précédemment pour de telles allocations. L'objet du présent document est de permettre à l'IANA de gérer de façon cohérente un certain nombre d'allocations sur la base de ces lignes directrices.

Le présent document réserve aussi certains numéros à l'expérimentation. Ces numéros sont données à la Section 3.

 	2.	Considérations relatives à l'IANA 

Les règles suivantes s'appliquent aux champs de ARP :

ar$hrd (16 bits) espace d'adresses de matériel : les demandes de valeurs pour ar$hrd en dessous de 256 ou pour un lot de plus d'une nouvelle valeur sont faites par revue d'expert [RFC5226]. Noter que certains protocoles, comme BOOTP et DHCPv4, emploient ces valeurs dans un champ de 8 bits. L'expert devrait déterminer qu'il existe un besoin d'allouer de nouvelles valeurs et que les valeurs existantes ne suffisent pas pour représenter les nouveaux types d'adresses de matériel. L'expert devrait aussi déterminer l'applicabilité de la demande et allouer des valeurs supérieures à 255 pour les demandes qui ne s'appliquent pas à BOOTP/DHCPv4. De même, l'expert devrait allouer des valeurs de un octet pour les demandes qui s'appliquent à BOOTP/DHCPv4, comme par exemple le "tunnel IPsec" de valeur 31 [RFC3456]. À l'inverse, les utilisation uniquement ARP, sans raison visible d'utiliser la même valeur que dans BOOTP/DHCPv4, devraient favoriser des valeurs de deux octets. Les demandes de valeurs individuelles ar$hrd nouvelles qui ne spécifient pas de valeur, ou si la valeur demandée est supérieure à 255, sont faites sur la base du principe du premier arrivé, premier servi [RFC5226]. L'allocation va toujours résulter en une valeur de deux octets.

ar$pro (16 bits) espace d'adresses de protocole : ces numéros partagent l'espace Ethertype. L'espace Ethertype est administré comme décrit dans la [RFC5342].

ar$op (16 bits) Opcode : les demandes pour de nouvelles valeurs de ar$op sont faites par revue de l'IETF ou approbation de l'IESG [RFC5226].

 	3.	Allocations définies dans le présent document

Lorsque on pratique des essais sur des idées de nouvelles extensions de protocole, il est souvent nécessaire d'utiliser une constante réelle afin d'utiliser la nouvelle fonction, même quand les essais sont pratiqués dans un environnement clos. Le présent document réserve les numéros suivants pour les expérimentations dans ARP :

o	Deux nouvelles valeurs de ar$hrd sont allouées pour les expérimentations : HW_EXP1 (36) et HW_EXP2 (256). Noter que ces deux nouvelles valeurs ont à dessein été choisies pour qu'une soit en dessous de 256 et l'autre au-dessus de 255, et qu'ainsi elles aient des valeurs différentes dans les octets de poids fort et de moindre poids.

o	Deux nouvelles valeurs pour ar$op sont allouées à des fins expérimentales : OP_EXP1 (24) et OP_EXP2 (25).

Noter que l'appendice B.2 de la [RFC5342] mentionne deux Ethertypes qui peuvent être utilisés à des fins expérimentales.

De plus, pour ar$hrd comme ar$op, les valeurs 0 et 65535 sont marquées comme réservées. Cela signifie qu'elles ne sont pas disponibles pour allocation.

 	4.	Considérations sur la sécurité

La présente spécification ne change pas les propriétés de sécurité des protocoles affectés.

Cependant, quelques mots sont nécessaires sur l'utilisation des codets expérimentaux définis à la Section 3. Les effets collatéraux potentiellement dommageables provenant de l'utilisation de valeurs expérimentales doivent être évalués soigneusement avant de déployer une expérience sur des réseaux que ne contrôle pas entièrement le propriétaire de l'expérience. Les lignes directrices données dans la [RFC3692] sur l'utilisation de valeurs expérimentales doivent être suivies.

 	5.	Remerciements

L'absence de toute règle actuelle est apparue lorsque de nouvelles valeurs ont été demandées à l'IANA, qui a contacté l'IESG pour avis. Les auteurs tiennent à remercier Michelle Cotton en particulier pour avoir soulevé ce problème. Les auteurs tiennent aussi à remercier Brian Carpenter, Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, Robert Sparks, Larry Zhu, et Dave Thaler de leurs retours.

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

[RFC0826]	D. Plummer, "Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet", STD 37, novembre 1982.

[RFC0951]	B. Croft et J. Gilmore, "Protocole BOOTSTRAP (BOOTP)", septembre 1985.

[RFC1044]	K. Hardwick et J. Lekashman, "Protocole Internet sur les systèmes réseau HYPERchannel – Spécification du protocole", STD 45, février 1988.

[RFC1329]	P. Kuehn, "Réflexions sur la résolution d'adresse pour les réseaux duels MAC FDDI", mai 1992. (Info.)

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)

[RFC2132]	S. Alexander et R. Droms, "Options DHCP et Extensions de fabricant BOOTP", mars 1997.

[RFC2176]	K. Murakami, M. Maruyama, "IPv4 sur MAPOS version 1", juin 1997. (Information)

[RFC2225]	M. Laubach, J. Halpern, "IP et ARP classiques sur ATM", avril 1998. (P.S. ; MàJ par RFC5494)

[RFC2834]	J.-M. Pittet, "Diffusion ARP et IP sur HIPPI-800", mai 2000. (P.S.)

[RFC2835]	J.-M. Pittet, "IP et ARP sur HIPPI-6400 (GSN)", mai 2000. (P.S.)

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227 ; rendue obsolète par RFC8415)

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

[RFC4338]	C. DeSanti et autres, "Transmission de paquets IPv6, IPv4, et du protocole de résolution d'adresse (ARP) sur canal en fibre", janvier 2006. (Remplace RFC3831, RFC2625) (P.S. ; MàJ par RFC8064)

[RFC4361]	T. Lemon, B. Sommerfeld, "Identifiants de client spécifique de nœud pour le protocole de configuration dynamique d'hôte version 4 (DHCPv4)", février 2006. (MàJ RFC2131, RFC2132, RFC3315) (P.S.)

[RFC4701]	M. Stapp et autres, "Enregistrement de ressource (RR) du DNS pour le codage des informations du protocole de configuration dynamique d'hôte (DHCP) ", octobre 2006. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5342]	D. Eastlake 3rd. "Considérations de l'IANA et utilisation du protocole de l'IETF pour les paramètres IEEE 802", septembre  2008. (BCP0141) (MàJ RFC2153 ; remplacée par RFC7042)

 	6.2	Références pour information

[RFC0903]	R. Finlayson, T. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d'adresse", STD 38, juin   1984.

[RFC1931]	D. Brownell, "Extensions RARP dynamiques pour l'acquisition automatique d'adresse réseau", avril 1996. (Information)

[RFC2390]	T. Bradley, C. Brown et A. Malis, "Protocole de résolution inverse d'adresse", septembre 1998. (D.S.)

[RFC3456]	B. Patel et autres, "Protocole de configuration dynamique des hôtes (DHCPv4) Configuration du mode tunnel IPsec", janvier  2003. (P.S.)

 	Appendice A.	Changements aux RFC originales

Le présent document spécifie seulement les règles de l'IANA associées aux divers champs dans ARP. La spécification de ces règles affecte aussi l'allocation des champs correspondants dans les protocoles énumérés à la Section 1 qui partagent le registre. Le présent document ne fait aucun changement au fonctionnement de ces protocoles.

 	Adresse des auteurs

Jari Arkko
Ericsson
Jorvas  02420
Finland
mél : jari.arkko@piuha.net

Carlos Pignataro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC  27709
USA
mél : cpignata@cisco.com