17. DHCP Server Solicitation (Sollicitation de serveur DHCP)

Cette section décrit comment un client localise les serveurs qui attribueront des adresses aux IA appartenant au client.

Le client est responsable de la création des IA et de la demande qu'un serveur attribue des adresses IPv6 à la IA. Le client crée d'abord une IA et lui assigne un IAID. Le client transmet ensuite un message Solicit contenant une option IA décrivant la IA. Les serveurs capables d'attribuer des adresses à la IA répondent au client avec un message Advertise. Le client initie alors un échange de configuration comme décrit dans la section 18.

Si le client acceptera un message Reply avec des attributions d'adresses engagées et d'autres ressources en réponse au message Solicit, le client inclut une option Rapid Commit (voir section 22.14) dans le message Solicit.

17.1. Client Behavior (Comportement du client)

Un client utilise le message Solicit pour localiser les serveurs DHCP configurés pour attribuer des adresses ou renvoyer d'autres paramètres de configuration sur le lien auquel le client est connecté.

17.1.1. Creation of Solicit Messages (Création de messages Solicit)

Le client définit le champ « msg-type » sur SOLICIT. Le client génère un ID de transaction et insère cette valeur dans le champ « transaction-id ».

Le client DOIT inclure une option Client Identifier pour s'identifier auprès du serveur. Le client inclut des options IA pour toute IA à laquelle il souhaite que le serveur attribue des adresses. Le client PEUT inclure des adresses dans les IA comme suggestion au serveur sur les adresses pour lesquelles le client a une préférence. Le client NE DOIT PAS inclure d'autre option dans le message Solicit, sauf ce qui est spécifiquement autorisé dans la définition des options individuelles.

Le client utilise des options IA_NA pour demander l'attribution d'adresses non temporaires et utilise des options IA_TA pour demander l'attribution d'adresses temporaires. Les options IA_NA et IA_TA, ou une combinaison des deux, peuvent être incluses dans les messages DHCP.

Le client DEVRAIT inclure une option Option Request (voir section 22.7) pour indiquer les options qui intéressent le client. Le client PEUT également inclure des instances de ces options qui sont identifiées dans l'option Option Request, avec des valeurs de données comme suggestions au serveur sur les valeurs de paramètres que le client souhaiterait voir renvoyées.

Le client inclut une option Reconfigure Accept (voir section 22.20) si le client est disposé à accepter des messages Reconfigure du serveur.

17.1.2. Transmission of Solicit Messages (Transmission de messages Solicit)

Le premier message Solicit du client sur l'interface DOIT être retardé d'un délai aléatoire compris entre 0 et SOL_MAX_DELAY. Dans le cas d'un message Solicit transmis lorsque DHCP est lancé par la découverte de voisinage IPv6, le délai donne la quantité de temps à attendre après que la découverte de voisinage IPv6 a provoqué l'invocation par le client du protocole de configuration automatique d'adresses avec état (stateful address autoconfiguration protocol) (voir section 5.5.3 de RFC 2462). Ce délai aléatoire désynchronise les clients qui démarrent en même temps (par exemple, après une panne de courant).

Le client transmet le message selon la section 14, en utilisant les paramètres suivants :

IRT   SOL_TIMEOUT
MRT   SOL_MAX_RT
MRC   0
MRD   0

Si le client a inclus une option Rapid Commit dans son message Solicit, le client termine le processus d'attente dès qu'il reçoit un message Reply avec une option Rapid Commit.

Si le client attend un message Advertise, le mécanisme de la section 14 est modifié comme suit pour l'utilisation dans la transmission de messages Solicit. L'échange de messages n'est pas terminé par la réception d'un Advertise avant l'expiration du premier RT. Au contraire, le client recueille les messages Advertise jusqu'à ce que le premier RT se soit écoulé. De plus, le premier RT DOIT être choisi pour être strictement supérieur à IRT en choisissant RAND strictement supérieur à 0.

Un client DOIT recueillir les messages Advertise pour les premiers RT secondes, à moins qu'il ne reçoive un message Advertise avec une valeur de préférence de 255. La valeur de préférence est transportée dans l'option Preference (section 22.8). Tout Advertise ne comportant pas d'option Preference est considéré comme ayant une valeur de préférence de 0. Si le client reçoit un message Advertise incluant une option Preference avec une valeur de préférence de 255, le client commence immédiatement un échange de messages initié par le client (comme décrit dans la section 18) en envoyant un message Request au serveur depuis lequel le message Advertise a été reçu. Si le client reçoit un message Advertise n'incluant pas d'option Preference avec une valeur de préférence de 255, le client continue d'attendre jusqu'à ce que le premier RT se soit écoulé. Si le premier RT s'écoule et que le client a reçu un message Advertise, le client DEVRAIT procéder à un échange de messages initié par le client en envoyant un message Request.

Si le client ne reçoit aucun message Advertise avant l'expiration du premier RT, il démarre le mécanisme de retransmission décrit dans la section 14. Le client termine le processus de retransmission dès qu'il reçoit un message Advertise quelconque, et le client agit sur le message Advertise reçu sans attendre d'autres messages Advertise.

Un client DHCP DEVRAIT choisir MRC et MRD égaux à 0. Si le client DHCP est configuré avec MRC ou MRD défini sur une valeur autre que 0, il DOIT cesser d'essayer de configurer l'interface si l'échange de messages échoue. Après que le client DHCP a cessé d'essayer de configurer l'interface, il DEVRAIT redémarrer le processus de reconfiguration après un événement externe quelconque, tel qu'une entrée utilisateur, un redémarrage système, ou lorsque le client est connecté à un nouveau lien.

17.1.3. Receipt of Advertise Messages (Réception de messages Advertise)

Le client DOIT ignorer tout message Advertise qui inclut une option Status Code contenant la valeur NoAddrsAvail, à l'exception que le client PEUT afficher le message d'état correspondant à l'utilisateur.

À la réception d'un ou plusieurs messages Advertise valides, le client sélectionne un ou plusieurs messages Advertise en fonction des critères suivants.

Ceux ayant la valeur de préférence du serveur la plus élevée sont préférés à tous les autres messages Advertise.
Au sein d'un groupe de messages Advertise ayant la même valeur de préférence du serveur, un client PEUT sélectionner les serveurs dont les messages Advertise publient des informations d'intérêt pour le client. Par exemple, le client peut choisir un serveur qui a renvoyé une publicité avec des options de configuration d'intérêt pour le client.
Le client PEUT choisir un serveur moins préféré si ce serveur possède un meilleur ensemble de paramètres publiés, tels que les adresses disponibles publiées dans les IA.

Une fois le(s) message(s) Advertise sélectionné(s), le client stocke généralement des informations sur chaque serveur, telles que la valeur de préférence du serveur, les adresses publiées, quand la publicité a été reçue, etc.

Si le client doit sélectionner un serveur alternatif au cas où un serveur choisi ne répondrait pas, le client choisit le serveur suivant selon les critères ci-dessus.

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

Si le client inclut une option Rapid Commit dans le message Solicit, il s'attend à un message Reply incluant une option Rapid Commit en réponse. Le client ignore tous les messages Reply qu'il reçoit qui n'incluent pas d'option Rapid Commit. Si le client reçoit un message Reply valide incluant une option Rapid Commit, il traite le message comme décrit dans la section 18.1.8. S'il ne reçoit pas ce message Reply et reçoit plutôt un message Advertise valide, le client traite le message Advertise comme décrit dans la section 17.1.3.

Si le client reçoit ultérieurement un message Reply valide incluant une option Rapid Commit, il soit :

traite le message Reply comme décrit dans la section 18.1.8, et ignore tous les messages Reply reçus en réponse au message Request, soit
traite tous les messages Reply reçus en réponse au message Request et ignore le message Reply incluant l'option Rapid Commit.

17.2. Server Behavior (Comportement du serveur)

Un serveur envoie un message Advertise en réponse aux messages Solicit valides qu'il reçoit pour annoncer la disponibilité du serveur au client.

17.2.1. Receipt of Solicit Messages (Réception de messages Solicit)

Le serveur détermine les informations sur le client et son emplacement comme décrit dans la section 11 et vérifie sa politique administrative concernant la réponse au client. Si le serveur n'est pas autorisé à répondre au client, le serveur ignore le message Solicit. Par exemple, si la politique administrative pour le serveur est qu'il ne peut répondre qu'à un client disposé à accepter un message Reconfigure, si le client indique par une option Reconfigure Accept dans le message Solicit qu'il n'acceptera pas de message Reconfigure, les serveurs ignorent le message Solicit.

Si le client a inclus une option Rapid Commit dans le message Solicit et que le serveur est configuré pour répondre avec des attributions d'adresses engagées et d'autres ressources, le serveur répond au Solicit avec un message Reply comme décrit dans la section 17.2.3. Sinon, le serveur ignore l'option Rapid Commit et traite le reste du message comme s'il n'y avait pas d'option Rapid Commit.

17.2.2. Creation and Transmission of Advertise Messages (Création et transmission de messages Advertise)

Le serveur définit le champ « msg-type » sur ADVERTISE et copie le contenu du champ transaction-id du message Solicit reçu du client dans le message Advertise. Le serveur inclut son propre identifiant de serveur dans une option Server Identifier et copie l'option Client Identifier du message Solicit dans le message Advertise.

Le serveur PEUT ajouter une option Preference pour transporter la valeur de préférence pour le message Advertise. L'implémentation du serveur DEVRAIT permettre à l'administrateur de définir une valeur de préférence du serveur. La valeur de préférence du serveur DOIT être définie par défaut à zéro à moins d'être configurée autrement par l'administrateur du serveur.

Le serveur inclut une option Reconfigure Accept si le serveur souhaite demander au client d'accepter des messages Reconfigure.

Le serveur inclut les options que le serveur renverra au client dans un message Reply ultérieur. Les informations de ces options peuvent être utilisées par le client dans la sélection d'un serveur si le client reçoit plus d'un message Advertise. Si le client a inclus une option Option Request dans le message Solicit, le serveur inclut dans le message Advertise des options contenant des paramètres de configuration pour toutes les options identifiées dans l'option Option Request que le serveur est configuré pour renvoyer au client. Le serveur PEUT renvoyer des options supplémentaires au client s'il est configuré pour le faire. Le serveur doit être conscient des recommandations sur les tailles de paquets et l'utilisation de la fragmentation dans la section 5 de RFC 2460.

Si le message Solicit du client incluait une ou plusieurs options IA, le serveur DOIT inclure des options IA dans le message Advertise contenant les adresses qui seraient attribuées aux IA contenues dans le message Solicit du client. Si le client a inclus des adresses dans les IA dans le message Solicit, le serveur utilise ces adresses comme suggestions sur les adresses que le client souhaiterait recevoir.

Si le serveur n'attribuera aucune adresse à aucune IA dans une Request ultérieure du client, le serveur DOIT envoyer un message Advertise au client qui n'inclut qu'une option Status Code avec le code NoAddrsAvail et un message d'état pour l'utilisateur, une option Server Identifier avec le DUID du serveur, et une option Client Identifier avec le DUID du client.

Si le message Solicit a été reçu directement par le serveur, le serveur envoie en unicast le message Advertise directement au client en utilisant l'adresse dans le champ adresse source du datagramme IP dans lequel le message Solicit a été reçu. Le message Advertise DOIT être envoyé en unicast sur le lien depuis lequel le message Solicit a été reçu.

Si le message Solicit a été reçu dans un message Relay-forward, le serveur construit un message Relay-reply avec le message Advertise dans la charge utile d'une option « relay-message ». Si les messages Relay-forward incluaient une option Interface-id, le serveur copie cette option dans le message Relay-reply. Le serveur envoie en unicast le message Relay-reply directement à l'agent de relais en utilisant l'adresse dans le champ adresse source du datagramme IP dans lequel le message Relay-forward a été reçu.

17.2.3. Creation and Transmission of Reply Messages (Création et transmission de messages Reply)

Le serveur DOIT engager l'attribution de toute adresse ou autre information de configuration avant d'envoyer un message Reply à un client en réponse à un message Solicit.

DISCUSSION :

Lors de l'utilisation de l'échange de messages Solicit-Reply, le serveur engage l'attribution de toute adresse avant d'envoyer le message Reply. Le client peut supposer que les adresses du message Reply lui ont été attribuées et n'a pas besoin d'envoyer un message Request pour ces adresses.

Typiquement, les serveurs configurés pour utiliser l'échange de messages Solicit-Reply seront déployés de sorte qu'un seul serveur réponde à un message Solicit. Si plus d'un serveur répond, le client utilisera uniquement les adresses de l'un des serveurs, tandis que les adresses des autres serveurs seront engagées pour le client mais non utilisées par le client.

Le serveur inclut une option Rapid Commit dans le message Reply pour indiquer que le Reply est en réponse à un message Solicit.

Le serveur inclut une option Reconfigure Accept si le serveur souhaite demander au client d'accepter des messages Reconfigure.

Le serveur produit le message Reply comme s'il avait reçu un message Request, comme décrit dans la section 18.2.1. Le serveur transmet le message Reply comme décrit dans la section 18.2.8.