Groupe de travail Réseau |
R. Droms, Bucknell University |
Request for Comments : 1534 |
|
Catégorie : Sur la voie de la normalisation |
|
Traduction Claude Brière de L'Isle |
octobre 1993 |
Inter fonctionnement DHCP - BOOTP
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 "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 copyright
Copyright (C) The Internet Society (2005).
Résumé
DHCP fournit un sur ensemble des fonctions assurées par BOOTP. Le présent document décrit les interactions entre les réseaux DHCP et BOOTP participants.
Le protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) fournit un mécanisme pour transmettre les paramètres de configuration aux hôtes en utilisant la suite de protocoles TCP/IP. Le format des messages DHCP se fonde sur le format des messages BOOTP, de sorte que, dans certaines circonstances, les participants DHCP et BOOTP peuvent échanger des messages. Le présent document spécifie les moyens par lesquels les participants DHCP et BOOTP peuvent interopérer.
DHCP introduit un petit changement de la terminologie destiné à préciser la signification d'un des champs. Ce qui est appelé champ "extensions de fabricant" dans BOOTP a été renommé le champ "options" dans DHCP. De même, les éléments de données étiquetés qui étaient utilisés dans le champ "extensions de fabricant" dans BOOTP, qui étaient précédemment appelés "extensions de fabricant", sont maintenant simplement appelés "options". Le présent document se réfère uniformément aux extensions de fabricant BOOTP et aux options DHCP comme à des "options".
Dans le présent document, les messages DHCP qui comportent une option de type de message DHCP seront désignés par le type du message ; par exemple, un message DHCP avec le type de message DHCP "option type 1" sera désigné comme message "DHCPDISCOVER".
2. Clients BOOTP et serveurs DHCP
Le format des messages DHCP est défini comme compatible avec le format des messages BOOTP, de sorte que les clients BOOTP existants peuvent interopérer avec les serveurs DHCP. Tout message reçu par un serveur DHCP qui comporte une option "type de message DHCP" (53) est supposé avoir été envoyé par un client DHCP. Les messages sans l'option Type de message DHCP sont supposés avoir été envoyés par un client BOOTP. La prise en charge des clients BOOTP par un serveur DHCP est facultative et à la discrétion de l'administrateur de système local. Si un serveur DHCP qui n'est pas configuré pour prendre en charge les clients BOOTP reçoit un message BOOTREQUEST d'un client BOOTP, ce serveur élimine en silence le message BOOTREQUEST.
Si un serveur DHCP est configuré à prendre en charge les clients BOOTP, il peut être configuré à fournir des adresses statiques, des adresses automatiques ou les deux. Les adresses statiques sont celles qui ont été préalablement allouées par un administrateur de système et sont mémorisées dans une base de données disponible au serveur DHCP. Les adresses automatiques sont celles qui sont choisies par le serveur DHCP à partir de son réservoir d'adresses non allouées.
Comme les clients BOOTP peuvent n'être pas prêts à recevoir des adresses automatiques, la décision de permettre à un serveur DHCP de retourner des adresses automatiques doit être prise sous le contrôle de l'administrateur du système. Si un serveur DHCP prend en charge la fourniture d'adresses automatiques à des clients BOOTP, cette caractéristique doit être configurable, et la caractéristique doit être désactivée par défaut. Activer la caractéristique doit être le résultat d'une décision active de l'administrateur du système.
Si un serveur DHCP retourne une adresse automatique, le client BOOTP ne connaîtra pas le mécanisme de prêt DHCP pour l'allocation d'adresse réseau. Donc, le serveur DHCP doit allouer une durée de prêt infinie pour les adresses automatiques allouées aux clients BOOTP. De telles adresses réseau ne peuvent pas être réallouées automatiquement par le serveur. L'administrateur de système local peut choisir de libérer manuellement les adresses réseau allouées aux clients BOOTP.
Un serveur DHCP qui prend en charge les clients BOOTP DOIT interagir avec les clients BOOTP selon le protocole BOOTP. Le serveur DOIT formuler un message BOOTP BOOTREPLY plutôt qu'un message DHCP DHCPOFFER (c'est-à-dire, le serveur NE DOIT PAS inclure l'option "Type de message DHCP" et NE DOIT PAS excéder la taille limite des messages BOOTREPLY). Le serveur marque un lien pour un client BOOTP comme BOUND après l'envoi de la BOOTREPLY BOOTP, car un non client DHCP ne va pas envoyer de message DHCPREQUEST et ce client n'attend pas de message DHCPACK.
Les serveurs DHCP PEUVENT envoyer toute option DHCP à un client BOOTP permise par la [RFC1533].
En résumé, un serveur DHCP :
o PEUT prendre en charge des clients BOOTP,
o PEUT retourner des adresses automatiques aux clients BOOTP,
o DOIT fournir une commutation de configuration si il retourne des adresses automatiques aux clients BOOTP,
o DOIT par défaut avoir cette configuration désactivée,
o DOIT respecter la spécification BOOTP quand il interagit avec des clients BOOTP,
o PEUT envoyer des options DHCP (celles qui sont définies dans le document sur les options DHCP mais pas dans les documents sur les extensions de fabricant BOOTP) à un client BOOTP.
3. Clients DHCP et serveurs BOOTP
Un client DHCP PEUT utiliser une réponse provenant d'un serveur BOOTP si la configuration retournée du serveur BOOTP est acceptable pour le client DHCP. Un client DHCP DOIT supposer qu'une adresse IP retournée dans un message d'un serveur BOOTP a une durée de prêt infinie. Un client DHCP DEVRAIT choisir d'utiliser une réponse provenant d'un serveur DHCP de préférence à une réponse provenant d'un serveur BOOTP.
4. Références
[RFC1531] R. Droms, "Protocole de configuration dynamique d'hôte", octobre 1993. (Obsolète, voir RFC2131)
[RFC1532] W. Wimer, "Éclaircissements et extensions au protocole Bootstrap", octobre 1993. (Remplacée par 1542)
[RFC1533] S. Alexander et R. Droms, "Options DHCP et extensions de fabricant BOOTP", octobre 1993. (Obsolète, voir 2132)
5. Considérations sur la sécurité
Les questions de sécurité ne sont pas discutées dans le présent mémoire.
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
USA
téléphone :(717) 524-1145
mél : droms@bucknell.edu