Groupe de travail Réseau	R. Woundy, Comcast Cable	
Request for Comments : 4388	K. Kinnear, Cisco Systems	
Catégorie:  Sur la voie de la normalisation	février 2006	
	Traduction Claude Brière de L'Isle	

Protocole Leasequery dans le protocole de configuration dynamique d'hôte (DHCP)

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 (2006). Tous droits réservés.

Résumé
Un serveur du protocole de configuration dynamique d'hôte version 4 (DHCPv4, Dynamic Host Configuration Protocol version 4) est la source d'autorité des adresses IP qu'il a fournies aux clients DHCPv4. Les autres processus et appareils qui utilisent déjà DHCPv4 peuvent avoir besoin d'accéder à ces informations. Le protocole Leasequery (interrogation sur les prêts) fournit à ces processus et appareils un moyen léger pour accéder aux informations d'adresse IP.
Table des matières
1. Introduction	2
2. Terminologie	3
3. Fondements	4
4. Buts de la conception	4
4.1 ARP en diffusion est indésirable	4
4.2 SNMP et LDAP ne sont pas appropriés	5
4.3 La fonction d'agent de relais DHCP est courante	5
4.4 Les serveurs DHCP sont une source fiable d'informations de localisation	5
4.5 Une configuration supplémentaire minimale est requise	5
5. Vue d'ensemble du protocole	5
6. Détails du protocole	7
6.1 Définitions requises pour le traitement de DHCPLEASEQUERY	7
6.2 Envoi du message DHCPLEASEQUERY	7
6.3 Réception du message DHCPLEASEQUERY	8
6.4 Réponse au message DHCPLEASEQUERY	9
6.5 Réception d'un message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN	11
6.6 Pas de réponse au message DHCPLEASEQUERY	11
6.7 Exigences de mémorisation de données de lien de prêt	12
6.8 Utilisation du message DHCPLEASEQUERY avec plusieurs serveurs DHCP	13
7. Considérations sur la sécurité	13
8. Considérations relatives à l'IANA	14
9. Remerciements	14
10. Références	14
10.1 Références normatives	14
10.2 Références pour information	14
Adresse des auteurs	15
Déclaration complète de droits de reproduction	15

 	1.	Introduction

Un serveur DHCPv4 contient un nombre considérable d'informations d'autorité concernant les adresses IP qu'il a prêtées aux clients DHCP. Parfois, les appareils ou autres processus peuvent avoir besoin d'accéder à ces informations. Dans certains cas, ces appareils ou processus ont déjà la capacité d'envoyer et recevoir des paquets DHCP, et donc le protocole Leasequery est conçu pour donner à ces processus et appareils une façon à faible frais généraux pour accéder à de telles informations.

Par exemple, les concentrateurs d'accès qui agissent comme des agents de relais DHCP déduisent parfois des informations importantes pour leur fonctionnement en extrayant des données des paquets PHCP qu'ils transmettent, processus connu sous le nom de "glanage". Malheureusement, le concentrateur d'accès normal perd les informations glanées quand il est réamorcé ou est remplacé. Le présent mémoire propose que quand des informations DHCP glanées ne sont pas disponibles, le concentrateur d'accès/agent de relais puisse obtenir les informations de localisation directement du ou des serveurs DHCP en utilisant le message DHCPLEASEQUERY.

Pour prolonger cet exemple, dans de nombreux réseaux d'accès à haut débit, le concentrateur d'accès a besoin d'associer un prêt d'adresse IP au point d 'extrémité de localisation correct, ce qui inclut la connaissance de l'adresse de matériel de l'hôte, l'accès ou le circuit virtuel qui conduit à cet hôte, et/ou l'adresse de matériel du modem d'abonné intervenant. Ceci est particulièrement important quand un ou plusieurs sous réseaux IP sont partagés entre plusieurs accès, circuits, et modems. Les environnements représentatifs de câble et DSL sont décrits dans les Figures 1 et 2.

        +--------+     +----------------+
        | Serveur|     | CMTS DOCSIS ou |
        |  DHCP  |-...-| INA DVB (agent |-------------------
        +--------+     |     de relais) |      |           |
                       +----------------+  +------+    +------+
                                           |Modem1|    |Modem2|
                                           +------+    +------+
                                              |         |    |
                                           +-----+  +-----+ +-----+
                                           |Hôte1|  |Hôte2| |Hôte3|
                                           +-----+  +-----+ +-----+

Figure 1 : Environnement câble pour DHCPLEASEQUERY

      +---------+     +-----------------+
      | Serveur |     |  Concentrateur  |     +--------+
      |  DHCP   |-...-|  d'accès DSL    |-...-| DSLAM  |
      +---------+     |(agent de relais)|     +--------+
                      +-----------------+      |      |
                                         +------+    +------+
                                         |Modem1|    |Modem2|
                                         +------+    +------+
                                              |        |    |
                                          +-----+  +-----+ +-----+
                                          |Hôte1|  |Hôte2| |Hôte3|
                                          +-----+  +-----+ +-----+

Figure 2 : Environnement DSL pour DHCPLEASEQUERY

La connaissance de ces informations de localisation peut bénéficier de plusieurs façons au concentrateur d'accès :
1.	Le concentrateur d'accès peut transmettre du trafic au réseau d'accès en utilisant l'accès correct du réseau d'accès, jusqu'au circuit virtuel correct, à travers le modem correct, à l'adresse de matériel correcte.
2.	Le concentrateur d'accès peut effectuer la vérification de l'adresse IP de source des datagrammes reçus du réseau d'accès. La vérification peut être fondée sur l'adresse du matériel source du datagramme, l'accès du réseau d'accès entrant, le circuit virtuel entrant, et/ou le modem transmetteur.
3.	Le concentrateur d'accès peut chiffrer des datagrammes qui ne peuvent être déchiffrés que par le modem correct, en utilisant des mécanismes tels que [BPI] ou [BPI+].

Le concentrateur d'accès dans cet exemple obtient les informations de localisation principalement du "glanage" des informations dans les réponses de serveur DHCP envoyées à travers l'agent de relais. Quand les informations de localisation du "glanage" ne sont pas disponibles, par exemple, parce que le concentrateur d'accès a réamorcé, le concentrateur d'accès peut interroger le ou les serveurs DHCP sur les informations de localisation en utilisant le message DHCPLEASEQUERY défini dans le présent document.

Le message DHCPLEASEQUERY est un nouveau type de message DHCP transmis d'un agent de relais DHCP à un serveur DHCP. Un agent de relais à capacité DHCPLEASEQUERY envoie le message DHCPLEASEQUERY quand il a besoin de savoir la localisation d'un point d'extrémité IP. Le serveur DHCP à capacité DHCPLEASEQUERY répond par un message DHCPLEASEUNASSIGNED (prêt DHCP non alloué), DHCPLEASEACTIVE (prêt DHCP actif), ou DHCPLEASEUNKNOWN (prêt DHCP inconnu). La réponse DHCPLEASEACTIVE à un message DHCPLEASEQUERY permet à l'agent de relais de déterminer la localisation du point d'extrémité IP et la durée restante du prêt d'adresse IP. DHCPLEASEUNASSIGNED est similaire à un message DHCPLEASEACTIVE, mais indique qu'il n'y a pas de prêt actuellement actif sur l'adresse IP résultante mais que ce serveur DHCP est d'autorité pour cette adresse IP. Le message DHCPLEASEUNKNOWN indique que le serveur DHCP n'a pas connaissance des informations spécifiées dans l'interrogation (par exemple, adresse IP, adresse MAC, ou option d'identifiant client).

Le message DHCPLEASEQUERY ne présuppose pas une utilisation particulière des informations qu'il retourne -- il est simplement conçu pour retourner les informations pour lesquelles le serveur DHCP est une source d'autorité pour un client qui demande cette information. Il est conçu pour les restituer directement aux processus et appareils qui interprètent déjà les paquets PHCP pour accéder aux informations provenant du serveur DHCP.

Le présent document spécifie une extension spécifiquement pour le protocole DHCPv4 [RFC2131]. Étant donnée la nature du protocole DHCPv6 [RFC3315], il n'y a pas de moyen effectif de produire une interaction commune du message DHCPLEASEQUERY entre DHCPv4 et DHCPv6 même si on désirait le faire.

Le message DHCPLEASEQUERY est le résultat d'un ensemble spécifique de besoins des mises en œuvre du monde réel qui sont apparus de nombreuses années après que le protocole DHCPv4 soit devenu d'utilisation courante. De plus, pour l'instant, le protocole DHCPv6 n'est pas encore largement déployé. Le besoin de concentrateurs d'accès dans les scénarios de déploiement encore à déterminer de DHCPv6 sont difficiles à estimer. Si une fonction comparable à celle de DHCPLEASEQUERY est nécessaire dans DHCPv6, beaucoup des idées du présent document vont probablement être applicables, mais peut-être pas toutes. On a essayé de ne pas concevoir des capacités de protocole qui n'auraient d'utilité que pour un consommateur imaginaire, et c'est tout ce qui existe aujourd'hui dans le domaine de DHCPLEASEQUERY pour DHCPv6.

Donc, le présent document s'applique seulement à DHCPv4, et pour être clair, nous n'avons pas ajouté DHCPv4 à chaque apparition de plusieurs termes courants. Dans ce document, toutes les références aux adresses IP devraient être prises comme signifiant une adresse IPv4, et toutes les références aux serveurs et clients DHCP comme des serveurs et clients DHCPv4.

 	2.	Terminologie

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

Le présent document utilise aussi les termes suivants :

Concentrateur d'accès : un concentrateur d'accès est un routeur ou commutateur à la bordure du fournisseur d'accès haut débit d'un réseau d'accès haut débit public. Le présent document suppose que le concentrateur d'accès inclut la fonction d'agent de relais DHCP.

Client DHCP : c'est un hôte Internet qui utilise DHCP pour obtenir des paramètres de configuration comme une adresse réseau.

Agent de relais DHCP : c'est un agent tiers qui transfère des messages du protocole Bootstrap (BOOTP) et DHCP entre les clients et serveurs résidant sur des sous-réseaux différents, conformément aux [RFC0951] et [RFC1542].

Serveur DHCP : hôte Internet qui retourne des paramètres de configuration aux clients DHCP.

Vers l'aval : c'est la direction du concentrateur d'accès vers l'abonné au haut débit.

Glanage : c'est l'extraction des informations de localisation des messages DHCP, lorsque les messages sont transmis par la fonction d'agent de relais DHCP.

Informations de localisation : ce sont les informations nécessaires au concentrateur d'accès pour transmettre le trafic à un hôte accessible par haut débit. Ces informations incluent la connaissance de l'adresse de matériel de l'hôte, l'accès ou le circuit virtuel qui conduit à l'hôte, et/ou l'adresse de matériel du modem d'abonné intercalé.

Adresse MAC : dans le contexte d'un paquet DHCP, une adresse MAC consiste en les champs suivants : type de matériel "htype", longueur de matériel "hlen", et adresse de matériel client "chaddr".

Mémorisation stable : chaque serveur DHCP est supposé avoir une forme de "mémorisation stable. La mémorisation stable est utilisée pour conserver les informations concernant les liens d'adresse IP (entre autres) afin qu'elles ne soient pas perdues en cas de défaillance du serveur exigeant son redémarrage.

Vers l'amont : c'est la direction de l'abonné haut débit vers le concentrateur d'accès.

 	3.	Fondements

L'objectif du présent document est de permettre aux processus et appareils qui souhaitent accéder aux informations du serveur DHCP de le faire d'une manière légère et pratique. Il est particulièrement approprié aux processus et appareils qui interprètent déjà les paquets PHCP.

Un important exemple de motivation est que le message DHCPLEASEQUERY permette aux concentrateurs d'accès d'envoyer des messages DHCPLEASEQUERY aux serveurs DHCP pour obtenir les informations de localisation des appareils du réseau d'accès haut débit.

Le présent document suppose que de nombreux concentrateurs d'accès ont une fonction d'agent de relais DHCP incorporée. Les concentrateurs d'accès typiques incluent des systèmes de terminaison de modem câble (CMTS, Cable Modem Termination System) DOCSIS [DOCSIS], des adaptateurs de réseau interactifs (INA, Interactive Network Adapter) DVB [EUROMODEM], et des concentrateurs d'accès DSL.

Le message DHCPLEASEQUERY est une extension du protocole DHCP [RFC2131].

Le message DHCPLEASEQUERY est seulement un message d'interrogation qui n'affecte pas l'état de l'adresse IP ou informations de lien qui lui sont associées.

 	4.	Buts de la conception

Le but de ce document est de fournir un mécanisme léger pour que les processus ou appareils accèdent aux informations contenues dans le serveur DHCP. Il est conçu de façon à permettre aux processus et appareils qui traitent et interprètent déjà les messages DHCP d'accéder à ces informations de manière rapide et légère.

Certaines de ces informations pourraient être acquises d'une façon différente, et les paragraphes qui suivent exposent certaines de ces approches.

 	4.1	ARP en diffusion est indésirable
Le concentrateur d'accès peut transmettre une demande du protocole de résolution d'adresse (ARP, Address Resolution Protocol) [RFC826] en diffusion, et observer l'origine et le contenu de la réponse ARP, pour reconstruire les informations de localisation.

Le mécanisme ARP est indésirable pour trois raisons :
1.	la charge sur le concentrateur d'accès pour transmettre sur plusieurs accès et circuits virtuels (en supposant que les sous réseaux IP s'étendent sur plusieurs accès ou circuits virtuels)
2.	la charge sur les nombreux hôtes d'abonnés pour recevoir et traiter la diffusion, et
3.	la facilité avec laquelle un hôte malveillant peut se faire passer pour le point d'extrémité IP.

 	4.2	SNMP et LDAP ne sont pas appropriés
Les mises en œuvre de concentrateur d'accès n'ont normalement pas d'interface client de gestion du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) ni d'interface client du protocole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol) (bien qu'elles incluent normalement des agents de gestion SNMP). C'est une des raisons pour laquelle le présent document ne reprend pas la proposition de MIB de serveur DHCP de [DHCPMIB].

L'effort de construction d'une MIB de serveur DHCP [DHCPMIB] s'est développé à partir de l'ingénierie du trafic et des activités de réparation sur les grandes installations DHCP, et est principalement destiné à être une méthode de collecte sur les serveurs de statistiques de performances de la charge qui leur est présentée.

En dépit de la présence dans la proposition de MIB de serveur DHCPv4 d'objets qui rapportent les informations de configuration et d'état, la MIB est destinée à fournir des données plus génériques, agrégées à l'échelle du serveur ou résumées. DHCPLEASEQUERY est destiné à fournir une information détaillée, spécifique sur des prêts individuels à un niveau qu'il serait difficile ou impossible d'adapter à une MIB.

Du point de vue de la mise en œuvre, il n'est pas exigé que le message DHCPLEASEQUERY soit pris en charge par tous les serveurs DHCPv4. Comme il apparaît que la définition d'objets de MIB facultatifs et d'objets pour des caractéristiques facultatives dans une MIB est déconseillée, essayer de prendre en charge facultativement la fonction LEASEQUERY dans une MIB va être similairement déconseillé du point de vue d'une MIB SNMP.

 	4.3	La fonction d'agent de relais DHCP est courante
Les concentrateurs d'accès agissent couramment comme agents de relais DHCP. De plus, de nombreux concentrateurs d'accès glanent déjà des informations de localisation dans les réponses de serveur DHCP, au titre de leur fonction d'agent de relais.

Le mécanisme de glanage comme technique de détermination des adresses IP valides pour une liaison particulière vers l'aval est préféré aux autres mécanismes (ARP, SNMP, LDAP) à cause du manque de trafic réseau supplémentaire, mais parfois les informations glanées peuvent être incomplètes. Le concentrateur d'accès ne peut généralement pas glaner des informations des messages DHCP en envoi individuel (c'est-à-dire, non relayés) pour des raisons de performances. De plus, les informations de localisation glanées par DHCP ne persistent souvent pas à travers les réamorçages de concentrateur d'accès (à cause du manque de mémorisation stable) et ne persistent presque jamais à travers les remplacements de concentrateur.

 	4.4	Les serveurs DHCP sont une source fiable d'informations de localisation
Les serveurs DHCP sont la source la plus fiable des informations de localisation pour les concentrateurs d'accès, en particulier quand les informations de localisation sont dynamiques et non reproductibles par des moyens algorithmiques (par exemple, quand un seul sous réseau IP s'étend derrière de nombreux modems haut débit). Les serveurs DHCP participent à toutes les transactions de prêt IP (et donc à toutes les mises à jour d'informations de localisation) avec les clients DHCP, tandis que les concentrateurs d'accès manquent parfois certaines transactions de prêt importantes.

Un concentrateur d'accès peut être configuré avec les adresses IP de plusieurs différents serveurs DHCP, de sorte qu'aucun serveur DHCP n'est un seul point de défaillance.

 	4.5	Une configuration supplémentaire minimale est requise
Les concentrateurs d'accès peuvent généralement interroger le même ensemble de serveurs DHCP qu'utilisé pour la transmission par l'agent de relais, minimisant ainsi les exigences de configuration.

 	5.	Vue d'ensemble du protocole

Dans l'exposé suivant sur le message DHCPLEASEQUERY, le client du message est supposé être un concentrateur d'accès. Noter que les concentrateurs d'accès ne sont pas les seuls consommateurs autorisés (ou requis) des informations fournies par le message DHCPLEASEQUERY, mais cela donne bien au lecteur une idée concrète de la façon dont le message pourrait être utilisé.

Le concentrateur d'accès initie toutes les conversations de message DHCPLEASEQUERY. Le présent document suppose que le concentrateur d'accès glane les informations de localisation dans sa fonction d'agent de relais DHCP. Cependant, les informations de localisation sont généralement indisponibles après le réamorçage ou le remplacement du concentrateur d'accès.

Supposons que le concentrateur d'accès soit un routeur, et supposons de plus que le routeur reçoive un datagramme IP à transmettre en aval au réseau d'accès public haut débit. Si les informations de localisation pour le prochain bon en aval manquent, le concentrateur d'accès envoie un ou plusieurs messages DHCPLEASEQUERY, contenant chacun l'adresse IP du prochain bond en aval dans le champ "ciaddr".

Cette interrogation va alors recevoir une réponse par le retour des informations actuelles sur quand le prêt de ce client a été accordé ou renouvelé pour la fois, permettant au concentrateur d'accès de transmettre le datagramme IP.

Une autre approche serait d'envoyer dans un message DHCPLEASEQUERY un champ "ciaddr" vide et l'adresse MAC (c'est-à-dire, les champs "htype", "hlen", et "chaddr") avec une adresse MAC valide ou une option Identifiant de client (option 61) apparaissant dans la zone des options. Dans ce cas, le serveur DHCP doit retourner une adresse IP dans le champ ciaddr si il a un enregistrement du client décrit par l'identifiant de client ou l'adresse MAC. En l'absence d'informations de configuration spécifiques du contraire (voir au paragraphe 6.4) ce DEVRAIT être l'adresse IP à l'heure de la dernière transaction du client associée au client décrit par l'adresse MAC ou l'option Identifiant de client.

Les serveurs DHCP qui mettent en œuvre ce protocole devraient toujours envoyer une réponse au message DHCPLEASEQUERY : DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN. Les raisons pour lesquelles un message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN pourrait être généré sont expliquées dans les régimes d'interrogation spécifiques ci-dessous.

Les serveurs qui ne mettent pas en œuvre le message DHCPLEASEQUERY DEVRAIENT simplement ne pas répondre.

Le message DHCPLEASEQUERY peut prendre en charge trois régimes d'interrogation : un serveur qui met en œuvre le message DHCPLEASEQUERY doit mettre en œuvre les trois régimes d'interrogation.

o	Interrogation par adresse IP : pour cette interrogation, le demandeur fournit seulement une adresse IP dans le message DHCPLEASEQUERY. Le serveur DHCP va retourner toutes les informations qu'il a sur le client le plus récent à qui il a alloué cette adresse IP. Le serveur DHCP répond par un message DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE si l'adresse IP dans le message DHCPLEASEQUERY correspond à une adresse IP sur laquelle le serveur a des informations définitives (c'est-à-dire, si il est autorisé à prêter cette adresse IP). Le serveur répond par un message DHCPLEASEUNKNOWN si le serveur n'a pas d'informations définitives concernant l'adresse contenue dans le message DHCPLEASEQUERY.

o	Interrogation par adresse MAC : pour cette interrogation, le demandeur fournit seulement une adresse MAC dans le message DHCPLEASEQUERY. Le serveur DHCP va retourner toutes les informations qu'il a sur l'adresse IP à laquelle a accédé un client qui a cette adresse MAC. De plus, il peut fournir des adresses IP supplémentaires qui ont été associées à cette adresse MAC dans différents sous réseaux. Les informations sur ces liens peuvent alors être trouvées en utilisant l'interrogation par adresse IP, décrite plus haut. Le serveur DHCP répond par un message DHCPLEASEACTIVE si l'adresse MAC dans le message DHCPLEASEQUERY correspond à une adresse MAC qui a un prêt actif sur une adresse IP dans ce serveur. Le serveur répond par un message DHCPLEASEUNKNOWN si le serveur n'a pas actuellement de prêt actif pour un client qui a cette adresse MAC dans ce serveur DHCP.

o	Interrogation par option d'identifiant de client : pour cette interrogation, le demandeur fournit seulement une option Identifiant de client dans le message DHCPLEASEQUERY. Le serveur DHCP va retourner toutes les informations qu'il a sur l'adresse IP à laquelle le client qui a cet identifiant de client a accédé le plus récemment. De plus, il peut fournir des adresses IP supplémentaires qui ont été associées à l'identifiant de client dans des sous réseaux différents. Les informations sur ces liens peuvent alors être trouvées en utilisant l'interrogation par adresse IP, décrite plus haut. Le serveur DHCP répond par un message DHCPLEASEACTIVE si l'identifiant de client dans le message DHCPLEASEQUERY a actuellement un prêt actif sur une adresse IP dans ce serveur DHCP. Le serveur répond par un message DHCPLEASEUNKNOWN si le serveur n'a pas de prêt actif pour un client qui a cet identifiant de client.

Pour de nombreux serveurs DHCP, l'interrogation par adresse IP est probablement la forme la plus efficace d'interrogation de prêt. C'est la forme de DHCPLEASEQUERY qui DEVRAIT être utilisée si possible.

Le message de réponse DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE doit toujours contenir l'adresse IP dans le champ "ciaddr". Le message DHCPLEASEACTIVE DEVRAIT contenir l'adresse physique du propriétaire du prêt d'adresse IP dans les champs "htype", "hlen", et "chaddr". La liste de demande de paramètre (option 55) peut être utilisée pour demander des options spécifiques à retourner au sujet de l'adresse IP dans le champ ciaddr. La réponse contient souvent le temps restant jusqu'à l'expiration du prêt, et le contenu original de l'option Informations d'agent de relais [RFC3046]. Le concentrateur d'accès utilise le champ "chaddr" et l'option Informations d'agent de relais pour construire les informations de localisation, qui peuvent être mises en antémémoire au concentrateur d'accès jusqu'à l'expiration du prêt.

Tous serveur DHCP qui prend en charge le message DHCPLEASEQUERY DEVRAIT sauvegarder les informations provenant de la plus récente option Informations d'agent de relais (option 82) [RFC3046] associée à chaque adresse IP qu'il dessert. On suppose que la plupart des clients qui génèrent le message DHCPLEASEQUERY vont demander l'option Informations d'agent de relais (option 82) dans la liste de demande de paramètre (option 55), et donc la prise en charge du message DHCPLEASEQUERY sans avoir l'option Informations d'agent de relais pour le retour au client est probablement très peu utile.

Un serveur qui met en œuvre DHCPLEASEQUERY DEVRAIT aussi sauvegarder les informations sur le plus récent identifiant de classe de fabricant, option 60, associée à chaque adresse IP, car cette option va probablement être demandée par les clients qui envoient le message DHCPLEASEQUERY.

 	6.	Détails du protocole
 	6.1	Définitions requises pour le traitement de DHCPLEASEQUERY
Le fonctionnement du message DHCPLEASEQUERY exige la définition des valeurs nouvelles et étendues suivantes pour le paquet DHCP au delà de celles définies par les [RFC2131] et [RFC2132]. Voir aussi à la Section 8, Considérations relatives à l'IANA.

1.	L'option Type de message (option 53) de la [RFC2132] exige quatre nouvelles valeurs : une pour le message DHCPLEASEQUERY lui-même et une pour chacune de ses trois réponses possibles DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. Les valeurs de ces types de messages sont montrées ci-dessous dans une extension au tableau du paragraphe 9.6 de la [RFC2132] :

Valeur	Type de message
10	DHCPLEASEQUERY
11	DHCPLEASEUNASSIGNED
12	DHCPLEASEUNKNOWN
13	DHCPLEASEACTIVE

 2.	Il y a une nouvelle option, heure de la dernière transaction du client : cette option permet au receveur de déterminer l'heure du plus récent accès du client. Elle est particulièrement utile quand des messages DHCPLEASEACTIVE provenant de deux différents serveurs DHCP ont besoin d'être comparés, mais elle peut être utile dans d'autres situations. La valeur est une durée en secondes depuis l'heure courante dans le passé quand cette adresse IP a été le plus récemment le sujet d'une communication entre le client et le serveur DHCP. Ceci NE DOIT PAS être un temps absolu. Ce NE DOIT PAS être un nombre absolu de secondes depuis le 1er janvier 1970. Ce DOIT être un nombre entier de secondes dans le passé à partir de l'instant de l'envoi du message DHCPLEASEACTIVE quand le client a pour la dernière fois traité avec ce serveur au sujet de cette adresse IP. De la même façon que l'option Temps de prêt d'adresse IP (option 51) code un temps de prêt qui est un nombre de secondes dans le futur à partir du moment de l'envoi du message, cette option code une valeur qui est un nombre de secondes dans le passé à partir de l'envoi du message.

Le code de cette option est 91. Sa longueur est 4 octets.

  Code Longueur  Secondes dans le passé
 +-----+-----+-----+-----+-----+-----+
 |  91 |  4  |  t1 |  t2 |  t3 |  t4 |
 +-----+-----+-----+-----+-----+-----+

3.	Il y a une seconde nouvelle option, l'option Adresse IP associée : associated-ip
Cette option est utilisée pour retourner toutes les adresses IP associées au client DHCP spécifié dans un message DHCPLEASEQUERY particulier.

Le code de cette option est 92. La longueur minimum pour cette option est 4 octets, et elle DOIT toujours être un multiple de 4.

  Code Longueur   Adresse 1              Adresse 2
 +-----+-----+-----+-----+-----+-----+-----+-----+--
 |  92 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
 +-----+-----+-----+-----+-----+-----+-----+-----+--

 	6.2	Envoi du message DHCPLEASEQUERY
Le message DHCPLEASEQUERY est normalement envoyé par un concentrateur d'accès. Le message DHCPLEASEQUERY utilise le format de message DHCP décrit dans la [RFC2131], et utilise le numéro de message 10 dans l'option Type de message DHCP (option 53). Le message DHCPLEASEQUERY a le contenu de message suivant :

o	Le champ giaddr DOIT être réglé à l'adresse IP du demandeur (c'est-à-dire, du concentrateur d'accès). Le champ giaddr est indépendant du champ "ciaddr" à rechercher -- il est simplement l'adresse de retour du message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN provenant du serveur DHCP.

Noter que cette utilisation de giaddr est cohérente avec la définition de giaddr dans la [RFC2131], où giaddr est toujours utilisé comme adresse de retour du message de réponse DHCP. Dans certains (mais pas tous) contextes de la RFC 2131, le giaddr est utilisé comme "clé" pour accéder au réservoir d'adresses approprié. Le message DHCPLEASEQUERY est un des cas où le giaddr NE DOIT PAS être utilisé comme une telle "clé".

o	L'option Liste de demande de paramètres (option 55) DEVRAIT être réglée aux options qui intéressent le demandeur. Les options intéressantes vont probablement inclure l'option Temps de prêt de l'adresse IP (option 51), l'option Informations d'agent de relais (option 82), et éventuellement l'option Identifiant de classe de fabricant (option 60). En l'absence d'une option Liste de demande de paramètres, le serveur DEVRAIT retourner les mêmes options qu'il aurait retournées pour un message DHCPREQUEST qui ne contiendrait pas de message DHCPLEASEQUERY, qui incluent celles rendues obligatoires par le paragraphe 4.3.1 de la [RFC2131] ainsi que toutes les options que le serveur a été configuré à toujours retourner à un client.

Les détails supplémentaires concernant les différents types d'interrogation sont :

o	Interrogation par adresse IP :
Les valeurs de htype, hlen, et chaddr DOIVENT être réglées à zéro.
Le champ "ciaddr" DOIT être réglé à l'adresse IP du prêt à interroger.
L'option Identifiant de client (option 61) NE DOIT PAS apparaître dans le paquet.

o	Interrogation par adresse MAC :
Les valeurs de htype, hlen, et chaddr DOIVENT être réglées à la valeur de l'adresse MAC à chercher.
Le champ "ciaddr" DOIT être réglé à zéro.
L'option Identifiant de client (option 61) NE DOIT PAS apparaître dans le paquet.

o	Interrogation par option Identifiant de client :
Il DOIT y avoir une option Identifiant de client (option 61) dans le message DHCPLEASEQUERY.
Le champ "ciaddr" DOIT être réglé à zéro.
Les valeurs de htype, hlen, et chaddr DOIVENT être réglées à zéro.

Le message DHCPLEASEQUERY DEVRAIT être envoyé à un serveur DHCP qui est connu pour posséder les informations d'autorité concernant l'adresse IP. Le message DHCPLEASEQUERY PEUT être envoyé à plus d'un serveur DHCP, et en l'absence d'informations concernant le serveur DHCP qui pourrait posséder les informations d'autorité concernant l'adresse IP, il DEVRAIT être envoyé à tous les serveurs DHCP configurés pour l'agent de relais associé (si il en est de connus).

Tout appareil qui s'attend à utiliser un message DHCPLEASEQUERY DEVRAIT s'assurer que l'option Informations d'agent de relais qu'il utilise contient les informations qui identifient sans ambiguïté l'appareil.

 	6.3	Réception du message DHCPLEASEQUERY
Un serveur qui met en œuvre le message DHCPLEASEQUERY DOIT mettre en œuvre les trois régimes d'interrogation : par adresse IP, par adresse MAC, et par identifiant de client.

Un message DHCPLEASEQUERY DOIT avoir un giaddr non de zéro. Le message DHCPLEASEQUERY DOIT avoir exactement un des suivants : un ciaddr non de zéro, un htype/hlen/chaddr non de zéro, ou une option Identifiant de client.

Le serveur DHCP qui reçoit un message DHCPLEASEQUERY DOIT fonder sa réponse sur l'élément de données particulier utilisé dans l'interrogation.

Le giaddr est utilisé seulement pour l'adresse de destination de toute réponse générée et, bien qu'exigée, n'est pas utilisée par ailleurs pour générer la réponse au message DHCPLEASEQUERY. Il NE DOIT PAS être utilisé pour restreindre le traitement de l'interrogation, et NE DOIT PAS être utilisé pour localiser un sous réseau auquel doit appartenir la ciaddr (si il en est une).

Noter que cette utilisation de giaddr est cohérente avec la définition de giaddr dans la [RFC2131], où le giaddr est toujours utilisé comme adresse de retour du message de réponse DHCP. Dans certains contextes (mais pas tous) de la RFC 2131, le giaddr est utilisé comme "clé" pour accéder au réservoir d'adresses approprié. Le message DHCPLEASEQUERY est un des cas où le giaddr NE DOIT PAS être utilisé comme une telle "clé".

 	6.4	Réponse au message DHCPLEASEQUERY
Il y a trois réponses possibles à un message DHCPLEASEQUERY :

o	DHCPLEASEUNASSIGNED : le serveur DOIT répondre par un message DHCPLEASEUNASSIGNED si ce serveur a des informations sur l'adresse IP, mais qu'il n'y a pas de prêt actif pour l'adresse IP. Le message DHCPLEASEUNASSIGNED est seulement retourné pour une interrogation par adresse IP, et indique que le serveur gère cette adresse IP, mais qu'il n'y a pas de prêt actuellement actif sur cette adresse IP.

o	DHCPLEASEUNKNOWN : le message DHCPLEASEUNKNOWN indique que le serveur ne gère pas l'adresse IP ou que le client spécifié dans le message DHCPLEASEQUERY n'a pas actuellement un prêt sur une adresse IP. Quand il répond par DHCPLEASEUNKNOWN, le serveur DHCP NE DOIT PAS inclure d'autre option DHCP dans la réponse.

o	DHCPLEASEACTIVE : le message DHCPLEASEACTIVE indique que le serveur non seulement connaît l'adresse IP et le client spécifiés dans le message DHCPLEASEACTIVE, mais aussi sait qu'il y a un prêt actif à ce client pour cette adresse IP.

Le serveur DOIT répondre avec un message DHCPLEASEACTIVE quand l'adresse IP retournée dans le champ "ciaddr" est actuellement prêtée.

 	6.4.1	Détermination de l'adresse IP à laquelle répondre
Comme la réponse à une demande DHCPLEASEQUERY peut seulement contenir les informations complètes sur une adresse IP – celle qui apparaît dans le champ "ciaddr" – la détermination de l'adresse IP sur laquelle répondre est une question clé. Bien sûr, les valeurs d'adresses IP supplémentaires pour lesquelles un client a un prêt doivent aussi être retournées dans l'option associated-ip (paragraphe 6.1, n° 3). C'est la seule information retournée non directement associée à l'adresse IP dans le champ "ciaddr".

Au cas où une adresse IP apparaît dans le champ "ciaddr" d'un message DHCPLEASEQUERY, si cette adresse IP est une de celles gérées par le serveur DHCP, alors cette adresse IP DOIT être établie dans le champ "ciaddr" d'un message DHCPLEASEUNASSIGNED.

Si l'adresse IP n'est pas gérée par le serveur DHCP, un message DHCPLEASEUNKNOWN doit alors être retourné.

Si le champ "ciaddr" du DHCPLEASEQUERY est zéro, alors le message DHCPLEASEQUERY est une interrogation par identifiant de client ou par adresse MAC. Dans ce cas, l'identité du client est tout client qui a proposé une option Identifiant de client identique (si l'option Identifiant de client apparaît dans le message DHCPLEASEQUERY) ou une adresse MAC  identique (si les champs Adresse MAC dans le message DHCPLEASEQUERY ne sont pas à zéro). Cette approche de confrontation de client sera, pour les besoins de ce paragraphe, décrite comme "identifiant de client ou adresse MAC".

Si le champ "ciaddr" est à zéro dans un message DHCPLEASEQUERY, alors l'adresse IP placée dans le champ "ciaddr" du message DHCPLEASEACTIVE DOIT être celle d'une adresse IP pour laquelle le client qui a le plus récemment utilisé l'adresse IP correspond à l'identifiant de client ou à l'adresse MAC spécifiée dans le message DHCPLEASEQUERY.

Si il n'y a qu'une seule adresse IP qui satisfasse ce critère, elle DOIT alors être placée dans le champ "ciaddr" du message DHCPLEASEACTIVE.

Dans le cas où le client spécifié par l'adresse MAC ou l'option Identifiant de client a accédé à plus d'une adresse IP, le serveur DHCP DOIT alors retourner l'adresse IP retournée au client dans la transaction la plus récente avec le client sauf si le serveur DHCP a été configuré par l'administrateur du serveur à utiliser un autre mécanisme de préférence.

Si après tout le traitement ci-dessus, aucune valeur n'est établie dans le champ "ciaddr" du message DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE, un message DHCPLEASEUNKNOWN DOIT alors être retourné à la place.

 	6.4.2	Construction d'un message DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE quand le champ "ciaddr" est établi
Une fois que le champ "ciaddr" de DHCPLEASEUNASSIGNED est réglé, le traitement d'un message DHCPLEASEUNASSIGNED est achevé. Aucune autre option n'est retournée pour le message DHCPLEASEUNASSIGNED.

Pour le message DHCPLEASEACTIVE, le reste du traitement implique principalement de retourner les informations sur l'adresse IP spécifiée dans le champ "ciaddr".

L'adresse IP dans le champ "ciaddr" du message DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE DOIT être une dont ce serveur est responsable (ou un message DHCPLEASEUNKNOWN aurait déjà été retourné plus tôt dans le traitement décrit au paragraphe précédent).

L'adresse MAC du message DHCPLEASEACTIVE DOIT être réglée à des valeurs qui identifient le client associé à l'adresse IP dans le champ "ciaddr" du message DHCPLEASEUNASSIGNED.

Si l'option Identifiant de client (option 61) est spécifiée dans l'option Liste de demande de paramètres (option 55) alors l'identifiant de client (s'il en est un) du client associé à l'adresse IP dans le champ "ciaddr" DEVRAIT être retourné dans le message DHCPLEASEACTIVE.

Dans le cas où plus d'une adresse IP a été impliquée dans un échange de messages DHCP avec le client spécifié par l'adresse MAC et/ou l'option Identifiant de client, alors la liste de toutes les adresses IP DOIT être retournée dans l'option associated-ip, que cette option ait ou non été demandée au titre de l'option Liste de demande de paramètres.

Si l'option Temps de prêt d'adresse IP (option 51) est spécifiée dans la liste de demande de paramètres et si il y a un prêt actuellement valide pour l'adresse IP spécifiée dans le champ ciaddr, le serveur DHCP DOIT alors retourner cette option dans le message DHCPLEASEACTIVE avec une valeur égale au temps restant jusqu'à l'expiration du prêt. Si il n'y a pas de prêt valide pour l'adresse IP, le serveur NE DOIT PAS retourner l'option Temps de prêt d'adresse IP (option 51).

Une demande d'option Valeur d'heure de renouvellement (T1) ou d'option Valeur d'heure de réinitialisation (T2) dans la liste de demande de paramètre du message DHCPLEASEQUERY DOIT être traitée comme l'option Heure de prêt d'adresse IP. Si il y a un prêt valide et si ces heures ne sont pas déjà passées, le serveur DHCP DEVRAIT alors retourner ces options (quand elles sont demandées) avec le temps restant jusqu'au renouvellement ou la réinitialisation, respectivement. Si ces heures sont déjà passées, ou si il n'y a pas de prêt actuellement valide pour cette adresse IP, le serveur DHCP NE DOIT PAS retourner ces options.

Si Informations d'agent de relais (option 82) est spécifié dans la liste de demande de paramètres, alors les informations contenues dans la plus récente option Informations d'agent de relais reçue de l'agent de relais associé à cette adresse IP DOIVENT être incluses dans le message DHCPLEASEACTIVE.

Le message DHCPLEASEACTIVE DEVRAIT inclure les valeurs de toutes les autres options non spécifiquement discutées ci-dessus qui ont été demandées dans la liste de demande de paramètres du message DHCPLEASEQUERY et qu'il est acceptable de retourner sur la base de la liste des "options non sensibles", discutée ci-dessous.

Les serveurs DHCP DEVRAIENT être configurables avec une liste "d'options non sensibles" qui peuvent être retournées au client quand elles sont spécifiées dans la liste de demande de paramètres du message DHCPLEASEQUERY. Toute option qui n'est pas sur cette liste NE DEVRAIT PAS être retournée au client, même si elle est demandée par ce client.

Le serveur DHCP utilise les informations provenant de sa base de données de liens de prêts pour fournir les valeurs d'option DHCPLEASEACTIVE. Les valeurs des options qui ont été retournées au client DHCP vont généralement être préférées, mais en leur absence, les options qui ont été envoyées dans les demandes de client DHCP vont être acceptables.

Dans certains cas, l'option Informations d'agent de relais dans un paquet DHCPREQUEST entrant est utilisée pour aider à déterminer les options retournées au client DHCP qui a envoyé la DHCPREQUEST. Quand il répond à un message DHCPLEASEQUERY, le serveur DHCP DOIT utiliser l'option Informations d'agent de relais sauvegardées tout comme il le fait quand il répond au client DHCP afin de déterminer les valeurs de toute option demandée par le message DHCPLEASEQUERY. Le but est de retourner les mêmes valeurs d'option au DHCPLEASEQUERY que celles retournées au DHCPDISCOVER ou DHCPREQUEST provenant du client DHCP (sauf spécification contraire ci-dessus).

Au cas où deux serveurs coopèrent pour fournir un serveur DHCP à haute disponibilité, comme défini dans la [RFC2131], ils devraient communiquer de l'un à l'autre des informations sur les liens d'adresse IP. Pour une prise en charge appropriée du message DHCPLEASEQUERY, ces serveurs DOIVENT s'assurer qu'ils se communiquent l'un à l'autre les informations d'option Informations d'agent de relais en plus de toute autre information de lien d'adresse IP.

 	6.4.3	Envoi d'un message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN
Le serveur attend une giaddr dans le message DHCPLEASEQUERY, et envoie le message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN en individuel à la giaddr. Si le champ "giaddr" est zéro, alors le serveur DHCP NE DOIT PAS répondre au message DHCPLEASEQUERY.

 	6.5	Réception d'un message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN
Quand un message DHCPLEASEACTIVE est reçu en réponse au message DHCPLEASEQUERY, cela signifie qu'il y a un prêt actuellement actif pour cette adresse IP dans ce serveur DHCP. Le concentrateur d'accès DEVRAIT utiliser les informations des champs "htype", "hlen", et "chaddr" de DHCPLEASEACTIVE ainsi que toutes les informations d'option Informations d'agent de relais incluses dans le paquet pour rafraîchir ses informations de localisation pour cette adresse IP.

Quand un message DHCPLEASEUNASSIGNED est reçu en réponse au message DHCPLEASEQUERY, cela signifie qu'il n'y a pas de prêt actuellement actif pour l'adresse IP présente dans le serveur DHCP, mais que ce serveur gère en fait cette adresse IP. Dans ce cas, le concentrateur d'accès DEVRAIT mettre ces informations en antémémoire afin d'empêcher une charge inacceptable sur le concentrateur d'accès et le serveur DHCP en présence d'un appareil malveillant ou sérieusement compromis en aval du concentrateur d'accès. Cette mise en antémémoire pourrait être de simplement établir un bit disant qu'une réponse a été reçue d'un serveur qui connaît cette adresse IP mais qu'il n'y a pas de prêt actuellement. Cela devrait, bien sûr, être remis à zéro quand le concentrateur d'accès "glane" ensuite qu'un prêt pour cette adresse IP est venu à l'existence.

Dans l'un et l'autre cas, quand un message DHCPLEASEUNASSIGNED ou DHCPLEASEACTIVE est reçu en réponse à un message DHCPLEASEQUERY, cela signifie que le serveur DHCP qui a répondu est un serveur DHCP qui gère l'adresse IP présente dans la ciaddr, et l'agent de relais DEVRAIT mettre ces informations en antémémoire pour utilisation ultérieure.

Quand un message DHCPLEASEUNKNOWN est reçu par un concentrateur d'accès qui a envoyé un message DHCPLEASEQUERY, cela signifie que le serveur DHCP contacté prend en charge le message DHCPLEASEQUERY mais que le serveur DHCP n'a pas d'informations définitives concernant l'adresse IP contenue dans le champ "ciaddr" du message DHCPLEASEQUERY. Si il n'y a pas d'adresse IP dans le champ "ciaddr" du message DHCPLEASEQUERY, un message DHCPLEASEUNKNOWN signifie alors que le serveur DHCP n'a pas d'informations définitives concernant le client DHCP spécifié dans les champs "hlen", "htype", et "chaddr" ou dans l'option Identifiant de client du message DHCPLEASEQUERY.

Le concentrateur d'accès DEVRAIT mettre ces informations en antémémoire, mais seulement pour une durée relativement courte, d'approximativement 5 minutes.

Ayant mis ces informations en antémémoire, le concentrateur d'accès DEVRAIT diriger seulement de façon non fréquente un message DHCPLEASEQUERY sur un serveur DHCP qui a répondu à un message DHCPLEASEQUERY pour un champ "ciaddr" particulier avec un DHCPLEASEUNKNOWN.

 	6.6	Pas de réponse au message DHCPLEASEQUERY
Quand un concentrateur d'accès ne reçoit pas de réponse à un message DHCPLEASEQUERY, il y a plusieurs raisons possibles :
o	Le DHCPLEASEQUERY ou un DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, ou DHCPLEASEUNKNOWN correspondant a été perdu durant la transmission, ou le DHCPLEASEQUERY est arrivé au serveur DHCP mais a été éliminé parce que le serveur était trop occupé.
o	Le serveur DHCP ne prend pas en charge DHCPLEASEQUERY.

Dans le premier cas, une retransmission de la DHCPLEASEQUERY serait appropriée, mais dans le second, elle ne le serait pas. Il n'y a pas de moyen de départager ces deux cas (autrement que, par exemple, parce que la réponse d'un serveur DHCP à d'autres messages DHCPLEASEQUERY indique qu'il prend ou ne prend pas en charge le message DHCPLEASEQUERY).

Un concentrateur d'accès qui utilise le message DHCPLEASEQUERY DEVRAIT tenter d'envoyer à nouveau les messages DHCPLEASEQUERY aux serveurs qui ne lui répondent pas en utilisant un algorithme de retardement pour l'instant du nouvel essai qui approxime un retard exponentiel. Le concentrateur d'accès DEVRAIT ajuster l'approche du retard exponentiel de façon à ce que les messages DHCPLEASEQUERY n'arrivent pas à un serveur qui n'est pas par ailleurs connu pour prendre en charge le message DHCPLEASEQUERY à un taux de plus qu'approximativement un paquet par 10 secondes, et donc (si le concentrateur d'accès a besoin d'envoyer des messages DHCPLEASEQUERY) pas moins d'une DHCPLEASEQUERY par 70 secondes.

En pratique, cette approche va probablement être mieux traitée par un temporisateur par serveur qui est relancé chaque fois qu'une réponse à un message DHCPLEASEQUERY est reçue, et expire après une minute. Le temporisateur par serveur démarrerait à partir de l'expiration, et dans l'état expiré, seulement un message DHCPLEASEQUERY serait mis en file d'attente pour le serveur associé.

Tous les messages DHCPLEASEQUERY DEVRAIENT utiliser l'algorithme de retard exponentiel spécifié au paragraphe 4.1 de la [RFC2131].

Donc, dans l'état initial, le temporisateur par serveur est arrivé à expiration, et un seul message DHCPLEASEQUERY est mise en file d'attente pour chaque serveur. Après la première réponse à un message DHCPLEASEQUERY, le temporisateur par serveur est lancé. À ce moment, plusieurs messages DHCPLEASEQUERY peuvent être envoyés en parallèle au serveur DHCP, bien que le nombre total DEVRAIT être limité à 100 ou 200, pour éviter d'inonder le serveur DHCP. Chacun de ces messages utilise l'algorithme de retard exponentiel de la [RFC2131]. Chaque fois qu'une réponse à un de ces messages est reçue, le temporisateur par serveur est réinitialisé et recommence à compter pendant une minute. Au cas où le temporisateur par serveur aurait une défaillance, tous les messages en cours DEVRAIENT alors être éliminés sauf un seul message DHCPLEASEQUERY qui sera utilisé pour interroger le serveur à des intervalles approximatifs de 64 secondes jusqu'à ce que soit reçue une autre réponse (ou la première) à la DHCPLEASEQUERY.

Au cas où il n'y aurait pas de trafic DHCPLEASEQUERY pendant une minute, le temporisateur par serveur va expirer. Après cela, il sera seulement permis à un message DHCPLEASEQUERY d'être en instance à ce serveur jusqu'à ce qu'une réponse soit reçue à ce message.

 	6.7	Exigences de mémorisation de données de lien de prêt
Les mises en œuvre de serveur DHCP qui appliquent la capacité DHCPLEASEQUERY DOIVENT sauvegarder la plus récente option Informations d'agent de relais provenant du plus récent paquet DHCPREQUEST pour deux raisons. D'abord, il est presque certain qu'elles seront demandées dans toute demande DHCPLEASEQUERY dans l'option Liste de demande de paramètres DHCP. Ensuite, l'option Informations d'agent de relais sauvegardée peut être nécessaire pour déterminer la valeur des autres options données au client DHCP, si elles sont demandées par la liste de demande de paramètres DHCP dans la demande DHCPLEASEQUERY.

Voici la liste des informations dont il est exigé qu'elles soient mises en œuvre avec succès :
o	option Information d'agent de relais provenant du paquet client : DOIT être mémorisée avec le lien.
o	heure de la dernière transaction du client de la dernière interaction du client : DOIT être mémorisée avec le lien.
o	identifiant de classe de fabricant : DEVRAIT être mémorisé avec le lien.

Ces exigences de mémorisation de données sont au minimum plus grandes que celles exigées pour le fonctionnement normal du protocole DHCP, comme exigé pour une mise en œuvre correcte de la [RFC2131].

 	6.8	Utilisation du message DHCPLEASEQUERY avec plusieurs serveurs DHCP
Quand on utilise le message DHCPLEASEQUERY dans un environnement où plusieurs serveurs DHCP peuvent contenir des informations d'autorité sur la même adresse IP (comme quand deux serveurs DHCP coopèrent pour fournir un service DHCP à haute disponibilité) plusieurs réponses, éventuellement contradictoires, pourraient être reçues.

Dans ce cas, certaines informations du paquet de réponse DEVRAIENT être utilisées pour décider entre les diverses réponses. L'heure de la dernière transaction du client (si elle est disponible) peut être utilisée pour décider quel serveur a les informations les plus récentes concernant l'adresse IP retournée dans le champ "ciaddr".

 	7.	Considérations sur la sécurité

Les concentrateurs d'accès qui utilisent le glanage DHCP, rafraîchi avec des messages DHCPLEASEQUERY, vont conserver des informations de localisation précises. La précision des informations de localisation assure que le concentrateur d'accès peut transmettre du trafic de données à la localisation prévue dans le réseau d'accès haut débit, peut effectuer la vérification d'adresse de source IP des datagrammes provenant du réseau d'accès, et peut chiffrer le trafic qui peut seulement être déchiffré par le modèle d'accès prévu (par exemple, [BPI] et [BPI+]). Par suite, le concentrateur d'accès n'a pas besoin de dépendre de diffusions ARP à travers le réseau d'accès, qui sont susceptibles d'être victimes d'hôtes malveillants qui se font passer pour les points d'extrémité IP prévus. Donc, le message DHCPLEASEQUERY permet à un concentrateur d'accès de fournir une sécurité considérablement améliorée.

Les serveurs DHCP DEVRAIENT empêcher l'exposition des informations de localisation (en particulier la transposition des adresses de matériel en adresses de prêt IP, qui peut être une intrusion dans la confidentialité de l'abonné haut débit) en employant les techniques détaillées dans la [RFC3118], "Authentification des messages DHCP".

La présente RFC décrit comment un client DHCP interagit avec un serveur DHCP. Les concentrateurs d'accès qui envoient le message DHCPLEASEQUERY sont essentiellement des clients DHCP pour les besoins du message DHCPLEASEQUERY, même si ils effectuent aussi les fonctions d'un agent de relais DHCP. Donc, la [RFC3118] est un mécanisme approprié pour les messages DHCPLEASEQUERY.

Comme la [RFC3118] discute des interactions normales de client DHCP, qui consistent en un message DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, et DHCPACK, il est nécessaire de transposer les opérations décrites dans la [RFC3118] dans le domaine DHCPLEASEQUERY. Les opérations décrites dans la [RFC3118] pour DHCPDISCOVER sont effectuées pour DHCPLEASEQUERY, et les opérations décrites pour DHCPOFFER sont effectuées pour les messages DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, et DHCPLEASEUNKNOWN.

Les concentrateurs d'accès DEVRAIENT minimiser les potentielles attaques de déni de service sur les serveurs DHCP en minimisant la génération de messages DHCPLEASEQUERY. En particulier, le concentrateur d'accès DEVRAIT employer la mise en antémémoire négative (c'est-à-dire, mettre en antémémoire les réponses DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, et DHCPLEASEUNKNOWN aux messages DHCPLEASEQUERY) et la restriction de ciaddr (c'est-à-dire, ne pas envoyer un message DHCPLEASEQUERY avec une ciaddr en dehors de la gamme des réseaux d'accès haut débit rattachés). Ensemble, ces mécanismes limitent le concentrateur d'accès à transmettre un seul message DHCPLEASEQUERY (excluant les réessais de messages) par adresse IP légitime de réseau d'accès haut débit après un événement de réamorçage.

Les serveurs DHCP qui prennent en charge le message DHCPLEASEQUERY DEVRAIENT s'assurer qu'ils ne peuvent pas être attaqués avec succès en étant submergés par de grandes quantités de messages DHCPLEASEQUERY en peu de temps.

Dans certains environnements, il peut être approprié de configurer un serveur DHCP avec les adresses IP des agents de relais pour lesquelles il peut répondre aux messages DHCPLEASEQUERY, lui permettant par là de ne répondre qu'aux demandes de seulement quelques agents de relais. Cela ne fournit pas une vraie sécurité, mais peut être utile pour déjouer des attaques non sophistiquées de diverses sortes.

 	8.	Considérations relatives à l'IANA

L'IANA a alloué six valeurs pour le présent document. Voir les détails au paragraphe 6.1. Il y a quatre nouveaux types de messages, qui sont la valeur de l'option Type de message (option 53) de la [RFC2132]. La valeur pour DHCPLEASEQUERY est 10, la valeur pour DHCPLEASEUNASSIGNED est 11, la valeur pour DHCPLEASEUNKNOWN est 12, et la valeur pour DHCPLEASEACTIVE est 13. Finalement, deux nouvelles options DHCP sont définies ; l'option Heure de la dernière transaction du client – code d'option 91, et l'option Adresse IP associée –code d'option 92.

 	9.	Remerciements

Jim Forster, Joe Ng, Guenter Roeck, et Mark Stapp ont largement contribué à la création initiale du message DHCPLEASEQUERY.

Patrick Guelat a suggéré plusieurs améliorations pour la prise en charge de l'adressage IP statique. Thomas Narten a fait de nombreuses suggestions d'améliorations. Russ Housley a insisté pour des capacités de sécurité accrues, et Ted Hardie a suggéré des moyens pour minimiser les fuites d'information non désirées. Bert Wijnen a suggéré qu'on précise notre orientation DHCPv4 et qu'on distingue notre approche de celle de la MIB DHCP. R. Barr Hibbs, un des auteurs de la MIB DHCP, a fourni des informations pour distinguer efficacement cet effort de celui de DHCPLEASEQUERY.

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

[RFC3046]	M. Patrick, "Option DHCP Information d'agent de relais", janvier 2001. (MàJ par RFC6607)

[RFC3118]	R. Droms et W. Arbaugh, "Authentification des messages DHCP", juin 2001. (P.S.) 

 	10.2	Références pour information

[BPI]	SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, disponible à http://www.scte.org/standards/ .

[BPI+]	CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", août 2005, disponible à http://www.cablemodem.com/ .

[DHCPMIB]	Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", Travail en cours, février 2004.

[DOCSIS]	SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, disponible à http://www.scte.org/standards/ .

[EUROMODEM]	ECCA, "Technical Specification of a European Cable Modem for digital bi-directional communications via cable networks", Version 1.0, May 1999.

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

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

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

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

 	Adresse des auteurs

Rich Woundy	Kim Kinnear	
Comcast Cable	Cisco Systems	
27 Industrial Ave.	1414 Massachusetts Ave	
Chelmsford, MA  01824	Boxborough, MA 01719	
USA	USA	
téléphone : (978) 244-4010	téléphone : (978) 936-0000	
mél : richard_woundy@cable.comcast.com 	mél : kkinnear@cisco.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 y 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 ci-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 actuellement assuré par la Internet Society.