Groupe de travail Réseau	S. Park & P. Kim, SAMSUNG Electronics	
Request for Comments : 4039	B. Volz, Cisco Systems	
Catégorie : Sur la voie de la normalisation	mars 2005	
	Traduction Claude Brière de L'Isle	

Option d'engagement rapide pour le protocole de configuration dynamique d'hôte version 4 (DHCPv4)

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é
Le présent document définit une nouvelle option du protocole de configuration dynamique d'hôte, version 4 (DHCPv4, Dynamic Host Configuration Protocol version 4) modélisée sur l'option Engagement rapide DHCPv6, pour obtenir les informations d'adresse IP et de configuration en utilisant un échange de deux messages plutôt que l'échange habituel à quatre messages, expédiant la configuration client.
Table des Matières
1. Introduction	1
2. Exigences	2
3. Opérations du client et du serveur	2
3.1 Flux détaillés	2
3.2 Considérations administratives	4
4. Format de l'option Engagement rapide	4
5. Considérations relatives à l'IANA	4
6. Considérations sur la sécurité	5
7. Références	5
7.1 Références normatives	5
7.2 Références pour information	5
8. Remerciements	5
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

1.	Introduction

Dans certains environnements, comme ceux où se produit la mobilité et que change fréquemment le point de rattachement au réseau, il est avantageux de configurer rapidement le client. Et, dans ces environnements, il est possible de configurer plus rapidement les clients parce que les protections offertes par l'échange normal (et plus long) de quatre messages peuvent n'être pas nécessaires. L'échange de quatre messages permet la redondance (plusieurs serveurs DHCP) sans gaspiller les adresses, car les adresses ne sont allouées que de façon provisoire à un client jusqu'à ce que le client choisisse et demande une des adresses provisoires allouées. L'échange à deux messages peut dont être utilisé lorsque un seul serveur est présent ou quand les adresses disponibles sont nombreuses et que de multiples serveurs qui engagent des adresses pour un client ne posent pas de problème.

Le présent document définit une nouvelle option Engagement rapide pour DHCPv4, modélisée sur l'option Engagement rapide de DHCPv6 [RFC3315], qui peut être utilisée pour initier un échange à deux messages pour expédier la configuration du client dans certains environnements. Un client annonce qu'il prend en charge cette option en l'envoyant dans les messages DHCPDISCOVER. Un serveur détermine alors si il permet l'échange à deux messages sur la base de ses informations de configuration et peut traiter le DHCPDISCOVER comme défini dans la [RFC2131] ou s'engager sur les informations de configuration du client et envoyer un message DHCPACK avec l'option Engagement rapide comme défini ci dessous.

2.	Exigences

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

3.	Opérations du client et du serveur

Si un client qui prend en charge l'option Engagement rapide a l'intention d'utiliser la capacité d'engagement rapide, il inclut une option Engagement rapide dans les messages DHCPDISCOVER qu'il envoie. Le client NE DOIT PAS l'inclure dans d'autres messages. Un client et un serveur n'utilisent cette option que quand ils sont configurés à le faire.

Un client qui envoie un DHCPDISCOVER avec l'option Engagement rapide traite les réponses comme décrit dans la [RFC2131]. Cependant, si le client reçoit un message DHCPACK avec une option Engagement rapide, il DEVRAIT traiter le DHCPACK immédiatement (sans attendre des messages DHCPOFFER ou DHCPACK supplémentaires) et utiliser les informations d'adresse et de configuration qui y sont contenues.

Un serveur qui prend en charge l'option Engagement rapide PEUT répondre à un message DHCPDISCOVER qui incluait l'option Engagement rapide avec un DHCPACK qui inclut l'option Engagement rapide, et engager pleinement l'adresse et les informations de configuration. Un serveur NE DOIT PAS inclure l'option Engagement rapide dans tout autre message.

L'option Engagement rapide NE DOIT PAS apparaître dans une option Liste de demande de paramètres [RFC2132].

Toutes les autres opérations DHCP sont comme documenté dans la [RFC2131].

3.1	Flux détaillés
Ce qui suit est la révision du paragraphe 3.1 de la [RFC2131], qui inclut le traitement de l'option Engagement rapide.

1.	Le client diffuse un message DHCPDISCOVER sur son sous réseau physique local. Si le client prend en charge l'option Engagement rapide et a l'intention d'utiliser la capacité d'engagement rapide, il inclut une option Engagement rapide dans le message DHCPDISCOVER. Le message DHCPDISCOVER PEUT inclure des options qui suggèrent des valeurs pour l'adresse de réseau et la durée du prêt. Les agents de relais BOOTP peuvent passer le message aux serveurs DHCP qui ne sont pas sur le même sous réseau physique.
2.	Chaque serveur peut répondre soit par un message DHCPOFFER, soit par un message DHCPACK avec l'option Engagement rapide (le dernier seulement si le DHCPDISCOVER contient une option Engagement rapide et si la politique de configuration du serveur permet l'utilisation de l'engagement rapide). Cela va inclure une adresse réseau disponible dans le champ 'yiaddr' (et les autres paramètres de configuration dans les options DHCP). Les serveurs qui envoient une DHCPOFFER n'ont pas besoin de réserver l'adresse réseau offerte, bien que le protocole fonctionne plus efficacement si le serveur évite d'allouer l'adresse réseau offerte à un autre client. Les serveurs qui envoient le message DHCPACK engagent le lien pour le client dans une mémorisation persistante avant d'envoyer le DHCPACK. La combinaison de l'identifiant client ou 'chaddr' et de l'adresse réseau allouée constitue un identifiant univoque pour le prêt au client et est utilisée par le client et le serveur pour identifier un prêt auquel tous les messages DHCP se réfèrent. Le serveur transmet le message DHCPOFFER ou DHCPACK au client, si nécessaire en utilisant l'agent de relais BOOTP.
Quand ils allouent une nouvelle adresse, les serveurs DEVRAIENT vérifier que l'adresse réseau offerte n'est pas déjà utilisée ; par exemple, le serveur peut sonder l'adresse offerte avec une demande d'écho ICMP.
Les serveurs DEVRAIENT être mis en œuvre de façon telle que les administrateurs de réseau PUISSENT choisir de désactiver les sondages des nouvelles adresses allouées.

La Figure 3 de la [RFC2131] montre les flux de l'échange normal à quatre messages. La Figure 1 ci-dessous montre l'échange à deux messages.
                    Serveur          Client        Serveur
                (non retenu)                       (retenu)
                      v               v               v
                      |               |               |
                      |     Début d'initialisation    |
                      |               |               |
                      | _____________/|\____________  |
                      |/DHCPDISCOVER  | DHCPDISCOVER \|
                      | w/Engag rapide| w/Engag rapide|
                      |               |               |
                  Détermine la        |          Détermine la
                 configuration        |         configuration
                      |               |     Engage la configuration
                      |       Collecte les réponses   |
                      |\              |  ____________/|
                      | \________     | / DHCPACK     |
                      | DHCPOFFER\    |/w/Engag rapide|
                      |  (éliminé)    |               |
                      |    Initialisation terminée    |
                      |               |               |
                      .               .               .
                      .               .               .
                      |               |               |
                      |      Fermeture en douceur     |
                      |               |               |
                      |               |\_____________ |
                      |               |  DHCPRELEASE \|
                      |               |               |
                      |               |        Élimine le prêt
                      |               |               |
                      v               v               v

Figure 1 : Diagramme des flux de messages quant l'engagement rapide est utilisé

3.	Le client reçoit un ou plusieurs messages DHCPOFFER ou DHCPACK (si l'option Engagement rapide est envoyée dans DHCPDISCOVER) de un ou plusieurs serveurs. Si un DHCPACK (avec l'option Engagement rapide) est reçu, le client peut immédiatement avancer à l'étape 5 ci-dessous si les paramètres de configuration offerts sont acceptables. Le client peut choisir d'attendre d'avoir plusieurs réponses. Le client choisit un serveur duquel il demande ou accepte les paramètres de configuration, sur la base des paramètres de configuration offerts dans les messages DHCPOFFER et DHCPACK. Si le client choisit un DHCPACK, il avance à l'étape 5. Autrement, le client diffuse un message DHCPREQUEST qui DOIT inclure l'option "identifiant de serveur" pour indiquer quel serveur il a choisi ; le message PEUT inclure d'autres options qui spécifient les valeurs de configuration désirées. L'option "Adresse IP demandée" DOIT être réglée à la valeur du 'yiaddr' dans le message DHCPOFFER provenant du serveur. Ce message DHCPREQUEST est diffusé et relayé à travers les agents de relais DHCP/BOOTP. Pour aider à s'assurer que tous les agents de relais BOOTP transmettent le message DHCPREQUEST au même ensemble de serveurs DHCP qui a reçu le message original DHCPDISCOVER, le message DHCPREQUEST DOIT utiliser la même valeur dans le champ d'en-tête de message DHCP "secs" et être envoyé à la même adresse de diffusion IP où le message original DHCPDISCOVER a été envoyé. Le client attend la fin de temporisation et retransmet le message DHCPDISCOVER si le client ne reçoit pas de message DHCPOFFER.
4.	Les serveurs reçoivent la diffusion de DHCPREQUEST du client. Les serveurs non retenus par le message DHCPREQUEST utilisent le message comme notification que le client a décliné les offres de ces serveurs. Le serveur retenu dans le message DHCPREQUEST engage le lien pour le client sur une mémorisation persistante et répond par un message DHCPACK contenant les paramètres de configuration pour le client demandeur. La combinaison de l'identifiant de client ou 'chaddr' et de l'adresse réseau allouée constitue un identifiant univoque pour le prêt au client et est utilisée par le client et le serveur pour identifier un prêt auquel on se réfère dans tous les messages DHCP. Tous les paramètres de configuration dans le message DHCPACK DEVRAIENT ne pas entrer en conflit avec ceux du message DHCPOFFER antérieur auquel le client répond. Le serveur NE DEVRAIT PAS vérifier l'adresse réseau offerte à ce moment. Le champ 'yiaddr' dans le message DHCPACK est rempli avec l'adresse réseau choisie.

Si le serveur retenu est incapable de satisfaire le message DHCPREQUEST (par exemple, l'adresse réseau demandée a déjà été allouée) le serveur DEVRAIT répondre par un message DHCPNAK.

Un serveur PEUT choisir de marquer les adresses offertes aux clients dans les messages DHCPOFFER comme indisponibles. Le serveur DEVRAIT marquer une adresse offerte à un client dans un message DHCPOFFER comme disponible si le serveur ne reçoit pas de message DHCPREQUEST de ce client.

5.	Le client reçoit le message DHCPACK avec les paramètres de configuration. Le client DEVRAIT effectuer une vérification finale sur les paramètres (par exemple, le protocole de résolution d'adresse (ARP, Address Resolution Protocol) pour l'adresse réseau allouée) et il note la durée du prêt spécifié dans le message DHCPACK. À ce point, le client est configuré. Si le client détecte que l'adresse est déjà utilisée (par exemple, grâce à l'utilisation de ARP) le client DOIT envoyer un message DHCPDECLINE au serveur, et il redémarre le processus de configuration. Le client DEVRAIT attendre un minimum de dix secondes avant de redémarrer le processus de configuration pour éviter un trafic réseau excessif en cas de boucle.

Si le client reçoit un message DHCPNAK, il redémarre le processus de configuration.

Le client attend la fin de la temporisation et retransmet le message DHCPREQUEST si le client n'a reçu de message ni DHCPACK ni DHCPNAK. Le client retransmet le DHCPREQUEST conformément à l'algorithme de retransmission du paragraphe 4.1 de la [RFC2131]. Le client devrait choisir de retransmettre le message DHCPREQUEST assez de fois pour obtenir une probabilité adéquate de contacter le serveur sans causer au client (et à l'utilisateur de ce client) une trop longue attente avant d'abandonner ; par exemple, un client qui retransmet comme décrit au paragraphe 4.1 de la [RFC2131] pourrait retransmettre quatre fois le message DHCPREQUEST, pour un délai total de 60 secondes, avant de redémarrer la procédure d'initialisation. Si le client ne reçoit de message ni DHCPACK ni DHCPNAK après avoir employé l'algorithme de retransmission, il revient à l'état INIT et redémarre le processus d'initialisation. Le client DEVRAIT notifier à l'utilisateur que le processus d'initialisation a échoué et qu'il redémarre.

6.	Le client peut choisir de renoncer à son prêt d'une adresse réseau en envoyant un message DHCPRELEASE au serveur. Le client identifie le prêt à libérer avec son identifiant de client ou son 'chaddr' et l'adresse réseau dans le message DHCPRELEASE. Si le client a utilisé un identifiant de client lorsque il a obtenu le prêt, il DOIT utiliser le même identifiant de client dans le message DHCPRELEASE.

3.2	Considérations administratives
Les administrateurs de réseau DOIVENT seulement activer l'utilisation de l'engagement rapide sur un serveur DHCP si une des conditions suivantes est satisfaite :
1.	le serveur est le seul serveur du sous réseau ;
2.	si plusieurs serveurs sont présents, ils peuvent chacun engager un lien pour tous les clients, et donc chaque serveur doit avoir un nombre suffisant d'adresses disponibles.
Un serveur PEUT permettre la configuration pour un temps de prêt initial différent (vraisemblablement plus court) pour les adresses allouées quand l'engagement rapide est utilisé pour expédier les réclamations d'adresses non utilisées par les clients.

4.	Format de l'option Engagement rapide

L'option Engagement rapide est utilisée pour indiquer l'utilisation de l'échange à deux messages pour l'allocation d'adresse. Le code pour l'option Engagement rapide est 80. Le format de l'option est :

Code : 80
Longueur : 0

Un client DOIT inclure cette option dans un message DHCPDISCOVER si le client est prêt à effectuer l'échange de messages DHCPDISCOVER-DHCPACK décrit plus haut.

Un serveur DOIT inclure cette option dans un message DHCPACK envoyé en réponse à un message DHCPDISCOVER lorsque il achève l'échange de messages DHCPDISCOVER-DHCPACK.

5.	Considérations relatives à l'IANA

L'IANA a alloué la valeur 80 comme code de l'option Engagement rapide conformément à la [RFC2939].

6.	Considérations sur la sécurité

Les concepts du présent document n'altèrent pas de façon significative les considérations de la sécurité pour DHCP (voir les [RFC2131] et [RFC3118]). Cependant, l'utilisation de cette option pourrait faciliter des attaques de déni de service en permettant à un client malveillant de consommer toutes les adresses disponibles plus rapidement ou de le faire sans exiger une communication bidirectionnelle (car injecter des messages DHCPDISCOVER avec l'option Engagement rapide est suffisant pour causer l'allocation d'une adresse par un serveur).

7.	Références
7.1	Références normatives

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

7.2	Références pour information

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

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

[RFC3118]	R. Droms et W. Arbaugh, "Authentification des messages DHCP", juin 2001. (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)

8.	Remerciements

Des remerciement particuliers à Ted Lemon et Andre Kostur pour leurs nombreux et précieux commentaires. Merci à Ralph Droms pour ses commentaires durant le dernier appel du groupe de travail. Merci à Noh-Byung Park et Youngkeun Kim pour leur soutient à ce travail. En particulier, les auteurs voudraient mentionner les contributions de mise en œuvre de Minho Lee de SAMSUNG Electronics.

Adresse des auteurs

Soohong Daniel Park	Pyungsoo Kim	Bernie Volz	
Mobile Platform Laboratory	Mobile Platform Laboratory	Cisco Systems, Inc.	
SAMSUNG Electronics	SAMSUNG Electronics	1414 Massachusetts Ave.	
416, Maetan-3dong, Yeongtong-Gu	416, Maetan-3dong, Yeongtong-Gu	Boxborough, MA 01719	
Suwon, Korea	Suwon, Korea	USA	
téléphone : +82-31-200-4508	téléphone : +82-31-200-4635	téléphone : +1-978-936-0382	
mél : soohong.park@samsung.com 	mél : kimps@samsung.com  	mél : volz@cisco.com 	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 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 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 ci encloses ne violent 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 pourrait ê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 actuellement fourni par la Internet Society.