19. DHCP Server-Initiated Configuration Exchange (Échange de configuration initié par le serveur DHCP)

Un serveur initie un échange de configuration pour amener les clients DHCP à obtenir de nouvelles adresses et d'autres informations de configuration. Par exemple, un administrateur peut utiliser un échange de configuration initié par le serveur lorsque les liens dans le domaine DHCP doivent être renumérotés. D'autres exemples incluent des modifications de l'emplacement des serveurs d'annuaire, l'ajout de nouveaux services tels que l'impression, et la disponibilité de nouveaux logiciels.

19.1. Server Behavior (Comportement du serveur)

Un serveur envoie un message Reconfigure pour amener un client à initier immédiatement un échange de messages Renew/Reply ou Information-request/Reply avec le serveur.

19.1.1. Creation and Transmission of Reconfigure Messages (Création et transmission de messages Reconfigure)

Le serveur définit le champ « msg-type » sur RECONFIGURE. Le serveur définit le champ transaction-id à 0. Le serveur inclut une option Server Identifier contenant son propre DUID et une option Client Identifier contenant le DUID du client dans le message Reconfigure.

Le serveur PEUT inclure une option Option Request pour informer le client des informations qui ont été modifiées ou des nouvelles informations qui ont été ajoutées. En particulier, le serveur spécifie l'option IA dans l'option Option Request si le serveur souhaite que le client obtienne de nouvelles informations sur les adresses. Si le serveur indique l'option IA dans l'option Option Request, le serveur DOIT inclure une option IA qui ne contient pas d'autres sous-options pour identifier chaque IA qui doit être reconfigurée sur le client.

En raison du risque d'attaques par déni de service contre les clients DHCP, l'utilisation d'un mécanisme de sécurité est obligatoire dans les messages Reconfigure. Le serveur DOIT utiliser l'authentification DHCP dans le message Reconfigure.

Le serveur DOIT inclure une option Reconfigure Message (définie dans la section 22.19) pour sélectionner si le client répond avec un message Renew ou avec un message Information-Request.

Le serveur NE DOIT PAS inclure d'autre option dans le message Reconfigure, sauf ce qui est spécifiquement autorisé dans la définition des options individuelles.

Un serveur envoie chaque message Reconfigure à un seul client DHCP, en utilisant une adresse IPv6 unicast d'une portée suffisante appartenant au client DHCP. Si le serveur ne dispose pas d'une adresse à laquelle il peut envoyer le message Reconfigure directement au client, le serveur utilise un message Relay-reply (comme décrit dans la section 20.3) pour envoyer le message Reconfigure à un agent de relais qui relaiera le message au client. Le serveur peut obtenir l'adresse du client (et de l'agent de relais approprié, si nécessaire) via les informations que le serveur possède sur les clients qui ont été en contact avec le serveur, ou via un agent externe.

Pour reconfigurer plus d'un client, le serveur envoie en unicast un message séparé à chaque client. Le serveur peut initier la reconfiguration de plusieurs clients simultanément ; par exemple, un serveur peut envoyer un message Reconfigure à d'autres clients alors que des échanges de messages de reconfiguration précédents sont encore en cours.

Le message Reconfigure amène le client à initier un échange de messages Renew/Reply ou Information-request/Reply avec le serveur. Le serveur interprète la réception d'un message Renew ou Information-request (selon ce qui a été spécifié dans le message Reconfigure original) par le client comme la satisfaction de la demande du message Reconfigure.

19.1.2. Timeout and Retransmission of Reconfigure Messages (Délai et retransmission de messages Reconfigure)

Si le serveur ne reçoit pas de message Renew ou Information-request du client dans les REC_TIMEOUT millisecondes, le serveur retransmet le message Reconfigure, double la valeur de REC_TIMEOUT et attend à nouveau. Le serveur continue ce processus jusqu'à ce que REC_MAX_RC tentatives infructueuses aient été effectuées, moment auquel le serveur DEVRAIT interrompre le processus de reconfiguration pour ce client.

Les valeurs par défaut et initiales pour REC_TIMEOUT et REC_MAX_RC sont documentées dans la section 5.5.

19.2. Receipt of Renew Messages (Réception de messages Renew)

Le serveur génère et envoie un message Reply au client comme décrit dans les sections 18.2.3 et 18.2.8, en incluant des options pour les paramètres de configuration.

Le serveur PEUT inclure des options contenant les IA et de nouvelles valeurs pour d'autres paramètres de configuration dans le message Reply, même si ces IA et ces paramètres n'avaient pas été demandés dans le message Renew par le client.

19.3. Receipt of Information-request Messages (Réception de messages Information-request)

Le serveur génère et envoie un message Reply au client comme décrit dans les sections 18.2.5 et 18.2.8, en incluant des options pour les paramètres de configuration.

Le serveur PEUT inclure des options contenant de nouvelles valeurs pour d'autres paramètres de configuration dans le message Reply, même si ces paramètres n'avaient pas été demandés dans le message Information-request par le client.

19.4. Client Behavior (Comportement du client)

Un client reçoit les messages Reconfigure envoyés au port UDP 546 sur les interfaces pour lesquelles il a obtenu des informations de configuration via DHCP. Ces messages peuvent être envoyés à tout moment. Étant donné que les résultats d'un événement de reconfiguration peuvent intéresser des programmes de couche applicative, le client DEVRAIT enregistrer ces événements, et PEUT notifier ces programmes de la modification via une interface spécifique à l'implémentation.

19.4.1. Receipt of Reconfigure Messages (Réception de messages Reconfigure)

À la réception d'un message Reconfigure valide, le client répond avec un message Renew ou un message Information-request comme indiqué par l'option Reconfigure Message (telle que définie dans la section 22.19). Le client ignore le champ transaction-id dans le message Reconfigure reçu. Pendant que la transaction est en cours, le client ignore silencieusement tout message Reconfigure qu'il reçoit.

DISCUSSION :

Le message Reconfigure agit comme un déclencheur qui signale au client de compléter un échange de messages réussi. Une fois que le client a reçu un Reconfigure, le client procède à l'échange de messages (en retransmettant le message Renew ou Information-request si nécessaire) ; le client ignore les messages Reconfigure ultérieurs jusqu'à ce que l'échange soit terminé. Les messages Reconfigure ultérieurs amènent le client à initier un nouvel échange.

Comment ce mécanisme fonctionne-t-il face à des messages Reconfigure en double ou retransmis ? Les messages en double seront ignorés car le client commencera l'échange après la réception du premier Reconfigure. Les messages retransmis soit déclencheront l'échange (si le premier Reconfigure n'avait pas été reçu par le client), soit seront ignorés. Le serveur peut interrompre la retransmission des messages Reconfigure au client dès qu'il reçoit le message Renew ou Information-request du client.

Il est possible qu'un Reconfigure en double ou retransmis soit suffisamment retardé (et livré hors ordre) pour arriver au client après que l'échange (lancé par le Reconfigure original) soit terminé. Dans ce cas, le client amènerait un échange redondant. La probabilité d'une livraison retardée et hors ordre est assez faible pour être ignorée. La conséquence de l'échange redondant est une inefficacité plutôt qu'un dysfonctionnement.

19.4.2. Creation and Transmission of Renew Messages (Création et transmission de messages Renew)

Lorsqu'il répond à un Reconfigure, le client crée et envoie le message Renew exactement de la même manière décrite dans la section 18.1.3, à l'exception que le client copie l'option Option Request et toute option IA du message Reconfigure dans le message Renew.

19.4.3. Creation and Transmission of Information-request Messages (Création et transmission de messages Information-request)

Lorsqu'il répond à un Reconfigure, le client crée et envoie le message Information-request exactement de la même manière décrite dans la section 18.1.5, à l'exception que le client inclut une option Server Identifier avec l'identifiant du message Reconfigure auquel le client répond.

19.4.4. Timeout and Retransmission of Renew or Information-request Messages (Délai et retransmission de messages Renew ou Information-request)

Le client utilise les mêmes variables et le même algorithme de retransmission qu'il utilise avec les messages Renew ou Information-request générés dans le cadre d'un échange de configuration initié par le client. Voir les sections 18.1.3 et 18.1.5 pour les détails. Si le client ne reçoit pas de réponse du serveur d'ici la fin du processus de retransmission, le client ignore et abandonne le message Reconfigure.

19.4.5. Receipt of Reply Messages (Réception de messages Reply)

À la réception d'un message Reply valide, le client traite les options et définit (ou redéfinit) les paramètres de configuration de manière appropriée. Le client enregistre et met à jour les durées de vie pour toutes les adresses spécifiées dans les IA du message Reply.