Groupe de travail Réseau	K. Fujisawa, Sony Corporation
Request for Comments : 2855	juin 2000
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

DHCP pour IEEE 1394

Statut du présent 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 (2000).

Résumé
La norme IEEE 1394-1995 concerne les bus en série à hautes performances. Comme 1394 utilise une méthode d'adressage de couche de liaison différente de l'IEEE802/Ethernet conventionnel, l'usage de certains champs doit être précisé pour réaliser l'interopérabilité. Le présent mémoire décrit l'usage spécifique de 1394 de certains champs de messages DHCP.

 	1.	Introduction

La norme IEEE 1394-1995 concerne les bus en série à hautes performances.Le groupe de travail IETF IP1394 a spécifié la méthode pour porter les datagrammes IPv4 et les paquets ARP 1394 sur un réseau IEEE1394 [RFC2734].

Le protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) [RFC2131] fournit un cadre pour passer les informations de configuration aux hôtes sur un réseau TCP/IP.

Comme 1394 utilise une méthode d'adressage de couche de liaison différente de celle de l'IEEE802/Ethernet conventionnel, l'usage de certains champs doit être précisé pour réaliser l'interopérabilité. le présent mémoire décrit l'usage spécifique par 1394 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.	Questions relatives à l'adresse de liaison 1394

Avec les protocoles de couche de liaison conventionnels, comme un Ethernet, le champ 'chaddr' (client hardware address, adresse de matériel de client) peut être utilisé pour retourner un message de réponse provenant d'un serveur DHCP (ou agent de relais) à un client. Comme une adresse de liaison 1394 (node_ID) est transitoire ne va pas persister à travers le pont 1394, on a choisi de ne pas la mettre dans le champ 'chaddr'. Un client DHCP devrait demander que le serveur envoie une réponse en diffusion en établissant le fanion BROADCAST quand l'ARP 1394 n'est pas encore possible.

Note : en général, l'utilisation d'une réponse en diffusion est déconseillée, mais on considère que l'impact dans un réseau 1394 ne pose pas de problème.

 	3.	Usage spécifique de 1394 des champs de message DHCP

Les règles suivantes devraient être utilisées quand un client DHCP est connecté à un réseau IEEE1394.

'htype' (hardware address type, type d'adresse de matériel) DOIT être 24 [ARPPARAM].

'hlen' (hardware address length, longueur d'adresse de matériel) DOIT être  0.

Le champ 'chaddr' (adresse de matériel de client) est réservé. L'envoyeur DOIT régler ce champ à zéro, et le receveur et l'agent de relais DOIVENT ignorer sa valeur à réception.

Un client DHCP sur 1394 DEVRAIT établir un fanion BROADCAST dans ses messages DHCPDISCOVER et DHCPREQUEST (et régler 'ciaddr' à zéro) pour s'assurer que le serveur (ou 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 'ciaddr'. L'adresse de couche de liaison sera résolue par l'ARP 1394.

L'option 'Identifiant de client' DOIT être utilisée dans les messages DHCP du client au serveur du fait de l'absence de 'chaddr'. L'option 'Identifiant de client' peut consister en toute sorte de données. Comme chaque nœud IP sur 1394 a un EUI-64 (identifiant unique de nœud de 64 bits) celui-ci fait un identifiant de client évident. Les clients 1394 DEVRAIENT inclure un identifiant EUI-64 dans l'option 'Identifiant de client'. La valeur de type pour le EUI-64 est 27 [ARPPARAM], et son format est illustré comme suit :

 Code  Long  Type    Identifiant de client
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|  61 |  9  | 27  |      EUI-64 (identifiant unique de nœud)      |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

Noter que l'utilisation d'autres types d'identifiant de client, comme un nom de domaine pleinement qualifié (FQDN, fully qualified domain name) n'est pas interdite par le présent mémoire.

Pour plus de détails, voir le paragraphe 9.14 "Identifiant de client" dans la [RFC2132].

 	4.	Considérations sur la sécurité

DHCP ne fournit actuellement aucun mécanisme d'authentification ou de sécurité. Les expositions potentielles aux attaques sont discutées à la Section 7 de la spécification du protocole DHCP [RFC2131].

Un client malveillant peut falsifier son identifiant EUI-64, et donc se faire passer pour un autre client.

 	Remerciements
L'auteur remercie les membres du groupe de travail Dynamic Host Configuration de leur relecture et de leurs précieux commentaires.

 	Références
[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.

[RFC2734]	P. Johansson, "IPv4 sur IEEE 1394", décembre 1999. (P.S.)

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

 	Adresse de l'auteur
Kenji Fujisawa
Sony Corporation
6-7-35, Kitashinagawa,
Shinagawa-ku, Tokyo, 141-0001 Japan

téléphone : +81-3-5448-8507
mél : fujisawa@sm.sony.co.jp 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2000).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, 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 fournis 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 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 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 (IASA) de l'IETF.