17. DHCP Server Solicitation (Sollicitation du serveur DHCP)

Cette section décrit comment un client localise un serveur qui assignera des adresses aux IA appartenant au client.

Le client est responsable de créer une IA et de demander au serveur d'assigner des adresses IPv6 à l'IA. Le client crée d'abord une IA et lui assigne un IAID. Le client envoie ensuite un message Solicit contenant des options IA qui décrivent l'IA. Les serveurs capables d'assigner des adresses à l'IA répondent au client avec un message Advertise. Le client initie ensuite l'échange de configuration décrit dans la section 18.

Si le client acceptera un message Reply contenant une assignation d'adresse engagée et d'autres ressources en réponse au message Solicit, le client inclut l'option Rapid Commit (voir section 22.14) dans le message Solicit.

17.1. Client Behavior (Comportement du client)

Le client utilise un message Solicit pour découvrir les serveurs DHCP configurés pour assigner des adresses ou retourner 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 "message type" à 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 d'identificateur de client pour s'identifier au serveur. Le client inclut des options IA pour toute IA pour laquelle le client souhaite que le serveur assigne des adresses. Le client peut inclure des adresses dans l'IA comme indication au serveur des adresses préférées par le client. Le client ne doit pas inclure d'autres options dans le message Solicit, sauf si explicitement autorisé dans la définition d'une option individuelle.

Le client utilise l'option IA_NA pour demander l'assignation d'adresses non temporaires et l'option IA_TA pour demander l'assignation d'adresses temporaires. L'option IA_NA ou IA_TA, ou une combinaison des deux, peut être incluse dans un message DHCP.

Le client devrait inclure une option Option Request (voir section 22.7) pour indiquer les options que le client souhaite recevoir. Le client peut en outre inclure des instances de ces options identifiées dans l'option Option Request, avec des valeurs de données comme indication au serveur des valeurs de paramètres que le client souhaite voir retournées.

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

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

Le premier message Solicit du client sur une interface doit être retardé d'une quantité de temps aléatoire entre 0 et SOL_MAX_DELAY. Dans le cas où un message Solicit est envoyé lorsque DHCP est initié par la découverte de voisins IPv6, le délai donne la quantité de temps à attendre après que la découverte de voisins IPv6 a amené le client à appeler le protocole d'autoconfiguration d'adresse avec état (voir section 5.5.3 de RFC 2462). Ce délai aléatoire désynchronise les clients qui démarrent simultanément (par exemple, après une panne de courant).

Le client envoie 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 l'option Rapid Commit dans son message Solicit, le client termine le processus d'attente immédiatement après avoir reçu un message Reply avec l'option Rapid Commit.

Si le client attend des messages Advertise, le mécanisme de la section 14 est modifié comme suit lorsqu'il est utilisé pour envoyer des messages Solicit. L'échange de messages ne se termine pas par la réception d'un Advertise avant que le premier RT ne soit écoulé. Au lieu de cela, le client collecte des messages Advertise jusqu'à ce que le premier RT soit écoulé. De plus, le premier RT doit être strictement supérieur à IRT en choisissant un RAND strictement supérieur à 0.

Le client doit collecter des messages Advertise pendant les premières RT secondes, sauf s'il reçoit 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 qui ne contient 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 contenant une option Preference avec une valeur de préférence de 255, le client initie immédiatement l'échange de messages initié par le client (comme décrit dans la section 18) en envoyant un message Request au serveur qui a envoyé le message Advertise. Si le client reçoit un message Advertise qui ne contient pas d'option Preference avec une valeur de préférence de 255, le client continue d'attendre jusqu'à ce que le premier RT soit écoulé. Si le premier RT est écoulé et que le client a reçu des messages Advertise, le client devrait continuer l'échange de messages initié par le client en envoyant un message Request.

Si le client ne reçoit aucun message Advertise avant que le premier RT ne soit écoulé, il commence le mécanisme de retransmission décrit dans la section 14. Le client termine le processus de retransmission immédiatement après avoir reçu un message Advertise, et le client agit sur le message Advertise reçu sans attendre d'autres messages Advertise.

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

Le client devrait ignorer tout message Advertise contenant une option de code de statut avec la valeur NoAddrsAvail. Cependant, le client peut afficher le message de statut associé à l'utilisateur.

Après avoir reçu un ou plusieurs messages Advertise valides, le client sélectionne un ou plusieurs messages Advertise basés sur les critères suivants.

Les messages Advertise avec la valeur de préférence de serveur la plus élevée sont préférés à tous les autres messages Advertise.
Dans un groupe de messages Advertise avec la même valeur de préférence de serveur, le client peut sélectionner un serveur dont le message Advertise annonce des informations d'intérêt pour le client. Par exemple, le client peut sélectionner un serveur qui a retourné un Advertise contenant des options de configuration d'intérêt pour le client.
Le client peut sélectionner un serveur avec une préférence inférieure si ce serveur a un meilleur ensemble de paramètres Advertise (par exemple, des adresses disponibles annoncées dans l'IA).

Lorsque le client sélectionne un message Advertise, le client enregistre généralement des informations sur chaque serveur (valeur de préférence du serveur, adresses annoncées, heure à laquelle l'Advertise a été reçu, etc.).

Si le serveur sélectionné ne répond pas, le client doit sélectionner un serveur alternatif en suivant les critères donnés ci-dessus pour sélectionner le serveur suivant.

17.1.4. Receipt of Reply Message (Réception de message Reply)

Si le client a inclus l'option Rapid Commit dans son message Solicit, il s'attend à un message Reply avec l'option Rapid Commit comme réponse. Le client rejette tout message Reply reçu qui ne contient pas l'option Rapid Commit. Si le client reçoit un message Reply valide avec l'option Rapid Commit, le client traite le message comme décrit dans la section 18.1.8. Si le client ne reçoit pas un tel message Reply et reçoit des messages Advertise valides, le client traite les messages Advertise comme décrit dans la section 17.1.3.

Si le client reçoit ensuite un message Reply valide avec l'option Rapid Commit, le client fait l'une des choses suivantes:

Traiter le message Reply comme décrit dans la section 18.1.8 et rejeter le message Reply reçu en réponse au message Request, ou
Traiter le message Reply reçu en réponse au message Request et rejeter le message Reply avec l'option Rapid Commit.

17.2. Server Behavior (Comportement du serveur)

Le serveur envoie un message Advertise en réponse à un message Solicit valide reçu pour informer le client de la disponibilité du serveur.

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 la politique administrative concernant la réponse au client. Si le serveur n'est pas autorisé à répondre au client, le serveur rejette le message Solicit. Par exemple, si la politique administrative du serveur est que le serveur ne peut répondre qu'aux clients qui sont disposés à accepter des messages Reconfigure, et que le client a indiqué dans l'option Reconfigure Accept dans le message Solicit qu'il n'acceptera pas de messages Reconfigure, le serveur rejette le message Solicit.

Si le client a inclus l'option Rapid Commit dans le message Solicit, et si le serveur est configuré pour répondre avec une assignation d'adresse engagée 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 si l'option Rapid Commit n'était pas présente.

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

Le serveur définit le champ "message type" à ADVERTISE et copie le contenu du champ transaction ID du message Solicit reçu du client dans le message Advertise. Le serveur inclut l'identificateur du serveur dans l'option Server Identifier et copie l'identificateur du client du message Solicit dans le message Advertise.

Le serveur peut ajouter une option Preference pour transporter la valeur de préférence du serveur dans le message Advertise. L'implémentation du serveur devrait permettre à l'administrateur du serveur de définir la valeur de préférence du serveur. Sauf configuration contraire par l'administrateur du serveur, la valeur de préférence du serveur devrait être zéro par défaut.

Si le serveur exige que le client accepte des messages Reconfigure, le serveur inclut l'option Reconfigure Accept.

Le serveur inclut les options qui seront retournées au client dans un message Reply ultérieur. Si le client reçoit plusieurs messages Advertise, les informations dans ces options peuvent être utilisées par le client pour sélectionner un serveur. Si le client a inclus une option Option Request dans le message Solicit, le serveur inclut des options contenant les paramètres de configuration pour toutes les options identifiées dans l'option Option Request que le serveur est configuré pour retourner au client. Le serveur peut retourner des options supplémentaires au client s'il est configuré pour le faire. Le serveur devrait être conscient des recommandations dans la section 5 de RFC 2460 concernant l'utilisation de la taille des paquets et de la fragmentation.

Si le message Solicit du client contient une ou plusieurs options IA, le serveur doit inclure des options IA dans le message Advertise contenant des adresses qui seront assignées à l'IA dans le message Solicit du client. Si le client a inclus des adresses dans l'IA dans le message Solicit, le serveur utilise ces adresses comme indication des adresses que le client souhaite recevoir.

Si le serveur n'assignera pas d'adresses à une IA dans un message Request ultérieur du client, le serveur doit envoyer au client un message Advertise contenant uniquement une option Server Identifier contenant le DUID du serveur, une option Client Identifier contenant le DUID du client, et une option Status Code avec le code NoAddrsAvail et un message de statut pour l'utilisateur.

Si le serveur a reçu le message Solicit directement, le serveur unicast le message Advertise au client en utilisant l'adresse dans le champ d'adresse source du datagramme IP qui a reçu le message Solicit. Le message Advertise doit être unicasté sur le lien sur 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 contenant le message Advertise dans la charge utile de l'option "Relay Message". Si le message Relay-forward contenait une option Interface-Id, le serveur copie cette option dans le message Relay-reply. Le serveur unicast le message Relay-reply à l'agent relais en utilisant l'adresse dans le champ d'adresse source du datagramme IP qui a reçu le message Relay-forward.

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

Le serveur doit engager l'assignation de toute adresse ou d'autres informations de configuration avant d'envoyer un message Reply au client en réponse à un message Solicit.

DISCUSSION:

Lors de l'utilisation de l'échange de messages Solicit-Reply, le serveur engage l'assignation de toute adresse avant d'envoyer le message Reply. Le client peut supposer qu'il a reçu l'assignation des adresses dans le message Reply 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épondra à un message Solicit. Si plus d'un serveur répond, le client n'utilisera que les adresses d'un des serveurs, tandis que les adresses des autres serveurs seront engagées au client mais non utilisées par le client.

Le serveur inclut l'option Rapid Commit dans le message Reply pour indiquer que le Reply répond à un message Solicit.

Si le serveur exige que le client accepte des messages Reconfigure, le serveur inclut l'option Reconfigure Accept.

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.