Groupe de travail Réseau	V. Kashyap, IBM
Request for Comments : 4390	avril 2006
Catégorie : Information	Traduction Claude Brière de L'Isle

Protocole de configuration dynamique d'hôte (DHCP) sur InfiniBand

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de 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).

Résumé
L'adresse de couche de liaison IP sur Infiniband (IPoIB) est de 20 octets. C'est plus que les 16 octets réservés pour l'adresse de matériel dans un message du protocole de configuration dynamique d'hôte/protocole Bootstrap (DHCP/BOOTP, Dynamic Host Configuration Protocol/Bootstrap Protocol). Cette inégalité impose des restrictions à l'utilisation des champs de message DHCP quand ils sont utilisés sur un réseau IPoIB. Le présent document décrit l'utilisation des champs de message DHCP quand on met en œuvre DHCP sur IPoIB.
Table des matières
1. Introduction	1
2. DHCP sur le mécanisme IPoIB	2
2.1 Usage spécifique de IPoIB des champs de message DHCP	2
2.2 Utilisation du fanion BROADCAST	2
3. Considérations sur la sécurité	2
4. Remerciements	3
5. Références	3
5.1 Références normatives	3
5.2 Références pour information	3
Adresse de l'auteur	3
Déclaration complète de droits de reproduction	3

 	1.	Introduction

Le protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) fournit un cadre pour passer des informations de configuration aux hôtes sur un IP réseau [RFC2131]. DHCP se fonde sur le protocole Bootstrap (BOOTP) [RFC951] en ajoutant la capacité d'une allocation automatique d'adresses réseau réutilisables et d'options de configuration supplémentaires [RFC2131], RFC2132].

Le serveur DHCP reçoit une demande de diffusion d'un client. Le serveur DHCP utilise l'adresse de matériel de l'interface du client pour envoyer une réponse en envoi individuel quand le client n'a pas encore d'adresse IP qui lui est allouée. Le champ "chaddr" dans le message DHCP porte l'adresse de matériel du client.

Le champ "chaddr" est long de 16 octets. L'adresse de couche de liaison IPoIB est longue de 20 octets [RFC4391]. Donc, l'adresse de couche de liaison IPoIB ne va pas tenir dans le champ "chaddr", rendant impossible au serveur DHCP l'envoi d'une réponse en envoi individuel au client.

Pour assurer l'interopérabilité, l'usage des champs et de la méthode pour les interactions avec DHCP doit être précisé. Le présent document décrit l'usage spécifique de IPoIB de certains champs de DHCP. Voir dans la [RFC2131] le mécanisme de DHCP et l'explication de chaque champ.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	DHCP sur le mécanisme IPoIB

Comme décrit ci-dessus, l'adresse de couche de liaison est indisponible au serveur DHCP parce que l'adresse de couche de liaison est plus grande que la longueur du champ "chaddr". Par suite, le serveur ne peut pas envoyer sa réponse au client en envoi individuel. Donc, un client DHCP DOIT demander que le serveur envoie une réponse en diffusion en établissant le fanion BROADCAST quand le protocole de résolution d'adresse  (ARP, Address Resolution Protocol) IPoIB n'est pas possible, c'est-à-dire, dans les situations où le client ne connaît pas son adresse IP.

La [RFC1542] déconseille l'usage d'une réponse en diffusion. Mais dans le cas de IPoIB, c'est une nécessité parce que le serveur ne reçoit pas d'adresse de couche de liaison. Pour désynchroniser les diffusions au démarrage d'un sous réseau, la [RFC2131] suggère qu'un client attende un délai aléatoire (1 à 10 secondes) avant d'initier la découverte de serveur. La même temporisation va étaler les réponses en diffusion du serveur DHCP générées suite à l'utilisation du bit BROADCAST.

L'adresse de matériel du client, "chaddr", est unique dans le sous réseau et donc peut être utilisée pour identifier une interface de client. Mais en l'absence d'un "chaddr" unique, un autre identifiant unique du client doit être utilisé.

Le protocole DHCP déclare que l'option "Identifiant de client" peut être utilisée comme valeur unique d'identifiant pour le client [RFC2132]. Cette valeur doit être unique au sein du sous réseau du client.

L'option "Identifiant de client" inclut une paire type et identifiant. L'identifiant inclus dans l'option "Identifiant de client" peut consister en une adresse de matériel ou tout autre valeur unique comme le nom DNS du client. Quand une adresse de matériel est utilisée, le champ Type devrait être un des types de matériel ARP dont la liste figure dans [ARPPARAM].

 	2.1	Usage spécifique de IPoIB des champs de message DHCP
Un client DHCP, quand il fonctionne sur une interface IPoIB, DOIT suivre les règles ci après :

"htype" (type d'adresse de matériel) DOIT être 32 [ARPPARAM].

"hlen" (longueur d'adresse de matériel) DOIT être 0.

Le champ"chaddr" (adresse de matériel du client) DOIT mis à zéro.

L'option "Identifiant de client" DOIT être utilisée dans les messages DHCP.

L'identifiant de client utilisé dans les messages DHCP DOIT se conformer à la [RFC4361].

 	2.2	Utilisation du fanion BROADCAST
Un client DHCP sur IPoIB DOIT établir le fanion BROADCAST dans les messages DHCPDISCOVER et DHCPREQUEST (et régler "ciaddr" à zéro) pour s'assurer que le serveur (ou l'agent de relais) diffuse sa réponse au client.

Note : comme décrit dans la [RFC2131], "ciaddr" DOIT être rempli avec l'adresse IP du client durant les états BOUND, RENEWING ou REBINDING ; donc, le fanion BROADCAST NE DOIT PAS être établi. Dans ces cas, le serveur DHCP envoie le message DHCPACK en envoi individuel à l'adresse contenue dans le champ "ciaddr". L'adresse de liaison va être résolue par ARP.

 	3.	Considérations sur la sécurité

La [RFC2131] décrit les considérations sur la sécurité pertinentes pour DHCP. Le présent document n'introduit aucun nouveau problème.

 	4.	Remerciements

Le présent document emprunte beaucoup à la [RFC2855]. Roy Larsen a relevé la discordance de longueur entre l'adresse de liaison IPoIB et le champ "chaddr" de DHCP.

 	5.	Références
 	5.1	Références normatives

[ARPPARAM]	 http://www.iana.org/numbers.html 

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

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

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

[RFC4391]	J. Chu, V. Kashyap, "Transmission de IP sur InfiniBand (IPoIB)", avril 2006. (P.S.)

 	5.2	Références pour information

[RFC1542]	W. Wimer, "Précisions et extensions au protocole Boostrap", octobre 1993. (D.S.)

[RFC2855]	K. Fujisawa, "DHCP pour IEEE 1394", juin 2000. (P.S.)

 	Adresse de l'auteur
Vivek Kashyap
15350, SW Koll Parkway
Beaverton
OR 97006
USA
téléphone : +1 503 578 3422
mél : vivk@us.ibm.com 

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (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 fourni par l'activité de soutien administratif de l'IETF (IASA).