18. DHCP Client-Initiated Configuration Exchange (Échange de configuration initié par le client DHCP)

Le client initie un échange de messages avec un ou plusieurs serveurs pour obtenir ou mettre à jour des informations de configuration d'intérêt. Le client peut initier un échange de configuration dans le cadre du processus de configuration du système d'exploitation, lorsqu'il est demandé par la couche application, lorsque l'autoconfiguration d'adresse sans état l'exige, ou lorsqu'il est nécessaire de prolonger les durées de vie des adresses (messages Renew et Rebind).

18.1. Client Behavior (Comportement du client)

Le client utilise les messages Request, Renew, Rebind, Release et Decline dans le cycle de vie normal des adresses. Il utilise Confirm pour valider les adresses lorsqu'il a peut-être déménagé vers un nouveau lien. Il utilise le message Information-request lorsqu'il a besoin d'informations de configuration mais n'a pas besoin d'adresses.

Si le client a une adresse source de portée suffisante que le serveur peut utiliser comme adresse de retour, et que le client a reçu l'option Server Unicast du serveur (section 22.12), le client devrait unicast tout message Request, Renew, Release et Decline au serveur.

Discussion:

L'utilisation de l'unicast peut éviter les délais dus au relais de messages par les agents relais, ainsi qu'éviter la surcharge des serveurs et les réponses dupliquées dues à la livraison de messages clients à plusieurs serveurs. Exiger que le client relaie tous les messages DHCP via des agents relais permet d'inclure des options d'agent relais dans tous les messages envoyés par le client. Le serveur devrait activer l'utilisation de l'unicast uniquement lorsque les options d'agent relais ne seront pas utilisées.

18.1.1. Creation and Transmission of Request Messages (Création et transmission de messages Request)

Le client utilise un message Request pour remplir les adresses d'une IA et obtenir d'autres informations de configuration. Le client inclut une ou plusieurs options IA dans le message Request. Le serveur retourne ensuite les adresses et d'autres informations sur l'IA au client dans les options IA du message Reply.

Le client génère un ID de transaction et insère cette valeur dans le champ "transaction ID".

Le client place l'identificateur du serveur de destination dans l'option Server Identifier.

Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client ajoute toute autre option appropriée, y compris une ou plusieurs options IA (si le client demande au serveur d'assigner des adresses réseau).

Le client doit inclure une option Option Request (voir section 22.7) pour indiquer les options que le client souhaite recevoir. Le client peut inclure des options avec des valeurs de données comme indication au serveur des valeurs de paramètres que le client souhaite voir retournées.

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

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

IRT: REQ_TIMEOUT
MRT: REQ_MAX_RT
MRC: REQ_MAX_RC
MRD: 0

Si l'échange de messages échoue, le client agit selon la politique locale du client. Des exemples d'actions que le client peut prendre incluent:

Sélectionner un autre serveur dans la liste des serveurs connus du client; par exemple, un serveur qui a répondu avec un message Advertise.
Initier le processus de découverte de serveur décrit dans la section 17.
Terminer le processus de configuration et signaler l'échec.

18.1.2. Creation and Transmission of Confirm Messages (Création et transmission de messages Confirm)

Chaque fois qu'un client a peut-être déménagé vers un nouveau lien, les préfixes des adresses assignées aux interfaces sur ce lien peuvent ne plus être appropriés au lien auquel le client est connecté. Des exemples de situations où le client a peut-être déménagé vers un nouveau lien incluent:

Redémarrage du client.
Le client est physiquement connecté à une connexion filaire.
Le client revient du mode veille.
Un client utilisant une technologie sans fil change de point d'accès.

Dans toute situation où le client a peut-être déménagé vers un nouveau lien, le client doit initier un échange de messages Confirm/Reply. Le client inclut dans son message Confirm toute IA assignée aux interfaces qui ont peut-être déménagé vers un nouveau lien, ainsi que les adresses associées à ces IA. Tout serveur qui répond indiquera si ces adresses sont appropriées au lien auquel le client est connecté, par le statut dans le message Reply qu'il retourne au client.

Le client définit le champ "message type" à CONFIRM. 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 au serveur. Le client inclut des options IA pour toutes les IA assignées à l'interface à partir de laquelle le message Confirm est envoyé. Les options IA incluent toutes les adresses que le client associe actuellement à ces IA. Le client devrait définir les champs T1 et T2 dans toute option IA_NA et les champs de durée de vie préférée et valide dans les options IA Address à 0, car le serveur ignorera ces champs.

Le premier message Confirm du client sur une interface doit être retardé d'une quantité de temps aléatoire entre 0 et CNF_MAX_DELAY. Le client envoie le message selon la section 14, en utilisant les paramètres suivants:

IRT: CNF_TIMEOUT
MRT: CNF_MAX_RT
MRC: 0
MRD: CNF_MAX_RD

Si le client ne reçoit pas de réponse avant la fin du processus de transmission de messages (comme décrit dans la section 14), le client devrait continuer à utiliser toute adresse IP, en utilisant les dernières durées de vie connues pour ces adresses, et devrait continuer à utiliser tout autre paramètre de configuration obtenu précédemment.

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

Pour prolonger les durées de vie valides et préférées des adresses associées à une IA, le client envoie un message Renew au serveur à partir duquel le client a obtenu les adresses contenues dans les options IA de l'IA. Le client inclut des options IA Address dans les options IA de l'IA pour les adresses associées à l'IA. Le serveur détermine les nouvelles durées de vie des adresses dans l'IA selon la configuration administrative du serveur. Le serveur peut également ajouter de nouvelles adresses à l'IA. Le serveur peut supprimer des adresses de l'IA en définissant les durées de vie préférées et valides de ces adresses à zéro.

Le serveur contrôle le moment où le client contacte le serveur pour prolonger les durées de vie des adresses assignées par les paramètres T1 et T2 assignés à l'IA.

Au temps T1 de l'IA, le client initie un échange de messages Renew/Reply pour prolonger les durées de vie de toute adresse dans l'IA. Le client inclut une option IA dans son message Renew contenant toutes les adresses actuellement assignées à l'IA.

Si le serveur définit T1 ou T2 à 0 (pour IA_NA) ou s'il n'y a pas de temps T1 ou T2 (pour IA_TA), le client peut envoyer des messages Renew ou Rebind respectivement selon la discrétion du client.

Le client définit le champ "message type" à RENEW. Le client génère un ID de transaction et insère cette valeur dans le champ "transaction ID".

Le client place l'identificateur du serveur de destination dans l'option Server Identifier.

Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client ajoute toute autre option appropriée, y compris une ou plusieurs options IA. Le client doit inclure la liste des adresses que le client associe actuellement à l'IA dans le message Renew.

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

IRT: REN_TIMEOUT
MRT: REN_MAX_RT
MRC: 0
MRD: Temps restant jusqu'à T2

L'échange de messages se termine lorsque le temps T2 est atteint (voir section 18.1.4). À ce moment, le client initie un échange de messages Rebind.

18.1.4. Creation and Transmission of Rebind Messages (Création et transmission de messages Rebind)

Au temps T2 de l'IA (atteint uniquement si le serveur auquel le message Renew a été envoyé au temps T1 n'a pas répondu), le client initie un échange de messages Rebind/Reply avec tout serveur disponible. Le client inclut une option IA dans le message Rebind contenant toutes les adresses actuellement assignées à l'IA.

Le client définit le champ "message type" à REBIND. Le client génère un ID de transaction et insère cette valeur dans le champ "transaction ID".

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

IRT: REB_TIMEOUT
MRT: REB_MAX_RT
MRC: 0
MRD: Temps restant jusqu'à l'expiration de toutes les durées de vie valides des adresses

L'échange de messages se termine lorsque toutes les durées de vie valides des adresses assignées à l'IA expirent (voir section 10). À ce moment, le client a plusieurs actions alternatives parmi lesquelles choisir. Par exemple:

Le client peut choisir d'utiliser un message Solicit pour identifier un nouveau serveur DHCP et envoyer un Request au nouveau serveur pour l'IA expirée.
Le client peut choisir de supprimer l'IA expirée et d'utiliser des adresses dans d'autres IA, car le client peut avoir d'autres adresses dans d'autres IA.

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

Le client utilise un message Information-request pour obtenir des informations de configuration sans assignation d'adresse.

Le client définit le champ "message type" à INFORMATION-REQUEST. 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 au serveur. Si le client n'inclut pas d'option Client Identifier, le serveur ne peut pas retourner d'options spécifiques au client au client. Ou, le serveur peut choisir de ne pas répondre du tout au message. Si le message Information-request est authentifié, le client doit inclure une option Client Identifier.

Le premier message Information-request du client sur une interface doit être retardé d'une quantité de temps aléatoire entre 0 et INF_MAX_DELAY. Le client envoie le message selon la section 14, en utilisant les paramètres suivants:

IRT: INF_TIMEOUT
MRT: INF_MAX_RT
MRC: 0
MRD: 0

18.1.6. Creation and Transmission of Release Messages (Création et transmission de messages Release)

Pour libérer une ou plusieurs adresses, le client envoie un message Release au serveur.

Le client définit le champ "message type" à RELEASE. Le client génère un ID de transaction et place cette valeur dans le champ "transaction ID".

Le client place l'identificateur du serveur qui a assigné les adresses dans l'option Server Identifier.

Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client inclut des options dans le champ "options" contenant les IA des adresses qu'il libère. Les adresses à libérer doivent être incluses dans l'IA. Les adresses d'une IA que le client souhaite continuer à utiliser ne doivent pas être ajoutées à l'IA.

Le client ne doit pas utiliser l'une des adresses qu'il libère comme adresse source dans le message Release ou dans les messages de transmission ultérieurs.

Comme le message Release peut être perdu, le client doit retransmettre le Release s'il ne reçoit pas de réponse. Cependant, il existe des scénarios (par exemple, lors de l'arrêt) où le client ne souhaite pas attendre le délai d'attente de retransmission normal avant d'abandonner. L'implémentation doit retransmettre au moins une fois, mais peut choisir de terminer le processus de retransmission tôt.

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

IRT: REL_TIMEOUT
MRT: 0
MRC: REL_MAX_RC
MRD: 0

Le client doit cesser d'utiliser toutes les adresses qu'il libère dès que le client initie le processus d'échange de messages Release. Si une adresse a été libérée mais que le Reply du serveur DHCP a été perdu, le client peut retransmettre le message Release et le serveur peut répondre avec un Reply indiquant le statut NoBinding. Par conséquent, le client ne traite pas un message Reply avec le statut NoBinding dans un échange de messages Release comme indiquant une erreur.

Notez que si le client ne peut pas libérer une adresse, chaque adresse assignée à une IA sera récupérée par le serveur lorsque la durée de vie valide de cette adresse expire.

18.1.7. Creation and Transmission of Decline Messages (Création et transmission de messages Decline)

Si un client détecte qu'une ou plusieurs des adresses assignées par le serveur sont déjà utilisées par un autre nœud, le client envoie un message Decline au serveur pour informer le serveur que les adresses sont suspectes.

Le client définit le champ "message type" à DECLINE. Le client génère un ID de transaction et place cette valeur dans le champ "transaction ID".

Le client place l'identificateur du serveur qui a assigné les adresses dans l'option Server Identifier.

Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client inclut des options dans le champ "options" contenant les IA des adresses qu'il décline. Les adresses à décliner doivent être incluses dans l'IA. Les adresses d'une IA que le client souhaite continuer à utiliser ne doivent pas être ajoutées à l'IA.

Le client ne doit pas utiliser l'une des adresses qu'il décline comme adresse source dans le message Decline ou dans les messages de transmission ultérieurs.

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

IRT: DEC_TIMEOUT
MRT: 0
MRC: DEC_MAX_RC
MRD: 0

Si une adresse a été déclinée mais que le Reply du serveur DHCP a été perdu, le client peut retransmettre le message Decline et le serveur peut répondre avec un Reply indiquant le statut NoBinding. Par conséquent, le client ne traite pas un message Reply avec le statut NoBinding dans un échange de messages Decline comme indiquant une erreur.

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

Lorsqu'un client reçoit un message Reply valide en réponse à un message Solicit (avec option Rapid Commit), Request, Confirm, Renew, Rebind ou Information-request, le client extrait les informations de configuration contenues dans le Reply. Le client peut choisir de signaler tout code de statut ou message des options de code de statut dans le message Reply.

Le client doit effectuer une détection d'adresse dupliquée [17] pour chaque adresse dans toute IA reçue dans le message Reply avant d'utiliser cette adresse pour le trafic. Si l'une des adresses s'avère être utilisée sur le lien, le client envoie un message Decline au serveur comme décrit dans la section 18.1.7.

Si le Reply a été reçu en réponse à un message Solicit (avec option Rapid Commit), Request, Renew ou Rebind, le client met à jour les informations enregistrées sur l'IA à partir des options IA contenues dans le message Reply:

Enregistrer les temps T1 et T2.
Ajouter de nouvelles adresses dans les options IA à l'IA enregistrée par le client.
Mettre à jour les durées de vie des adresses dans les options IA que le client a déjà enregistrées dans l'IA.
Supprimer de l'IA enregistrée par le client les adresses avec une durée de vie valide de 0 dans les options IA Address.
Laisser inchangées les informations sur les adresses que le client a enregistrées dans l'IA mais que le serveur n'a pas incluses dans l'IA.

La gestion d'informations de configuration spécifiques est décrite en détail dans la définition de chaque option dans la section 22.

Si le client reçoit un message Reply avec un code de statut contenant UnspecFail, le serveur indique qu'il n'a pas pu traiter le message en raison d'une condition d'échec non spécifiée. Si le client retransmet le message original au même serveur pour réessayer l'opération souhaitée, le client devrait limiter la vitesse à laquelle il retransmet le message et limiter la durée pendant laquelle il retransmet le message.

Si le client reçoit un message Reply avec une option de code de statut avec la valeur UseMulticast, le client enregistre la réception du message et envoie des messages ultérieurs au serveur en utilisant le multicast via l'interface sur laquelle le message a été reçu. Le client retransmet le message original en utilisant le multicast.

Si le client reçoit un statut NotOnLink du serveur en réponse à un message Confirm, le client exécute la sollicitation du serveur DHCP comme décrit dans la section 17 et exécute la configuration initiée par le client comme décrit dans la section 18. Si le client reçoit un message Reply qui n'indique pas le statut NotOnLink, le client peut utiliser les adresses dans l'IA et peut ignorer les messages qui indiquent le statut NotOnLink.

Si le client reçoit un statut NotOnLink du serveur en réponse à un Request, le client peut réémettre le Request sans spécifier d'adresses, ou peut redémarrer le processus de découverte du serveur DHCP (voir section 17).

Le client examine le code de statut dans chaque IA individuellement. Si le code de statut est NoAddrsAvail, le client n'a pas reçu d'adresses disponibles dans l'IA et peut choisir d'essayer d'obtenir des adresses pour l'IA à partir d'un autre serveur. Le client utilise les adresses et autres informations de toute IA qui ne contient pas d'option de code de statut avec le code NoAddrsAvail. Si le client ne reçoit pas d'adresses dans une IA, le client peut essayer un autre serveur (peut-être en redémarrant le processus de découverte du serveur DHCP) ou peut utiliser un message Information-request pour obtenir uniquement d'autres informations de configuration.

Si le client reçoit un message Reply en réponse à un message Renew ou Rebind, le client examine chaque IA individuellement. Pour chaque IA dans le message Renew ou Rebind original, le client:

Si l'IA contient une option de code de statut avec le statut NoBinding, envoie un message Request (ne pas envoyer de messages Renew/Rebind supplémentaires)
Si l'IA n'est pas dans le message Reply, envoie Renew/Rebind
Sinon, accepte les informations dans l'IA

Si le client reçoit un message Reply valide en réponse à un message Release, le client considère que l'événement Release est terminé, indépendamment du code de statut retourné par le serveur dans l'option de code de statut.

Si le client reçoit un message Reply valide en réponse à un message Decline, le client considère que l'événement Decline est terminé, indépendamment du code de statut retourné par le serveur dans l'option de code de statut.

18.2. Server Behavior (Comportement du serveur)

Dans cette discussion, on suppose que le serveur est configuré d'une manière spécifique à l'implémentation avec des configurations d'intérêt pour le client.

Dans la plupart des cas, le serveur envoie un Reply en réponse à un message client. Ce message Reply doit toujours contenir une option Server Identifier contenant le DUID du serveur et une option Client Identifier du message client (si présente).

Dans la plupart des messages Reply, le serveur inclut des options contenant les informations de configuration du client. 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 client a inclus une option Option Request dans le message, 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.

18.2.1. Receipt of Request Messages (Réception de messages Request)

Si le serveur reçoit un message Request en unicast d'un client auquel le serveur n'a pas envoyé l'option Server Unicast, le serveur rejette le message Request et répond avec un message Reply contenant une option de code de statut avec la valeur UseMulticast, une option Server Identifier contenant le DUID du serveur, une option Client Identifier du message client, et aucune autre option.

Si le serveur reçoit un message Request valide, le serveur crée une liaison pour ce client selon la politique et les informations de configuration du serveur et enregistre les IA et autres informations demandées par le client.

Le serveur construit un message Reply en définissant le champ "message type" à REPLY et en copiant le transaction ID du message Request dans le champ transaction ID.

Le serveur doit inclure une option Server Identifier contenant le DUID du serveur et une option Client Identifier du message Request dans le message Reply.

Si le serveur découvre que le préfixe d'une ou plusieurs adresses IP dans toute IA dans le message client n'est pas approprié au lien auquel le client est connecté, le serveur doit retourner l'IA au client avec une option de code de statut avec la valeur NotOnLink.

Si le serveur ne peut pas assigner d'adresses à une IA dans le message client, le serveur doit inclure une IA dans le message Reply sans adresses dans l'IA et avec une option de code de statut avec le code NoAddrsAvail dans l'IA.

Pour toute IA pour laquelle le serveur peut assigner des adresses, le serveur inclut une IA contenant les adresses et autres paramètres de configuration et enregistre l'IA comme nouvelle liaison client.

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

Le serveur inclut d'autres options contenant les informations de configuration retournées au client comme décrit dans la section 18.2.

Si le serveur découvre que pour une IA que le client a incluse dans le message Request, le serveur a déjà une liaison pour l'IA avec le client, le client retransmet un message Request pour lequel il n'a pas reçu de Reply. Le serveur peut retransmettre le message Reply précédemment mis en cache ou envoyer un nouveau message Reply.

18.2.2. Receipt of Confirm Messages (Réception de messages Confirm)

Si le serveur reçoit un message Confirm, le serveur détermine si les adresses dans le message Confirm sont appropriées au lien auquel le client est connecté. Si toutes les adresses dans le message Confirm passent ce test, le serveur retourne un statut de succès. Si l'une des adresses ne passe pas ce test, le serveur retourne un statut NotOnLink. Si le serveur ne peut pas effectuer ce test (par exemple, le serveur n'a pas d'informations sur les préfixes sur le lien auquel le client est connecté), ou s'il n'y a pas d'adresses dans toute IA envoyée par le client, le serveur ne doit pas envoyer de Reply au client.

Le serveur ignore les champs T1 et T2 dans les options IA et les champs de durée de vie préférée et valide dans les options IA Address.

Le serveur construit un message Reply en définissant le champ "message type" à REPLY et en copiant le transaction ID du message Confirm dans le champ transaction ID.

Le serveur doit inclure une option Server Identifier contenant le DUID du serveur et une option Client Identifier du message Confirm dans le message Reply. Le serveur inclut une option de code de statut indiquant le statut du message Confirm.

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

Si le serveur reçoit un message Renew en unicast d'un client auquel le serveur n'a pas envoyé l'option Server Unicast, le serveur rejette le message Renew et répond avec un message Reply contenant une option de code de statut avec la valeur UseMulticast, une option Server Identifier contenant le DUID du serveur, une option Client Identifier du message client, et aucune autre option.

Si le serveur reçoit un message Renew contenant des options IA d'un client, le serveur identifie la liaison du client et vérifie que les informations dans l'IA du client correspondent aux informations stockées pour ce client.

Si le serveur ne peut pas trouver d'entrée client pour l'IA, le serveur retourne une IA au client dans le message Reply sans adresses contenant une option de code de statut définie à NoBinding.

Si le serveur découvre que l'une des adresses n'est plus appropriée au lien auquel le client est connecté, le serveur retourne l'adresse au client avec une durée de vie valide de 0.

Si le serveur trouve les adresses de l'IA du client, le serveur renvoie l'IA au client avec de nouvelles durées de vie et des temps T1/T2. Le serveur peut choisir de modifier la liste des adresses dans l'IA retournée au client et les durées de vie des adresses.

Le serveur construit un message Reply en définissant le champ "message type" à REPLY et en copiant le transaction ID du message Renew dans le champ transaction ID.

Le serveur doit inclure une option Server Identifier contenant le DUID du serveur et une option Client Identifier du message Renew dans le message Reply.

Le serveur inclut d'autres options contenant les informations de configuration retournées au client comme décrit dans la section 18.2.

18.2.4. Receipt of Rebind Messages (Réception de messages Rebind)

Si le serveur reçoit un message Rebind contenant des options IA d'un client, le serveur identifie la liaison du client et vérifie que les informations dans l'IA du client correspondent aux informations stockées pour ce client.

Si le serveur ne peut pas trouver d'entrée client pour l'IA et que le serveur détermine selon les informations de configuration explicites du serveur que les adresses dans l'IA ne sont pas appropriées à l'interface du client connectée au lien, le serveur peut envoyer un message Reply au client contenant l'IA du client avec les durées de vie valides des adresses dans l'IA définies à zéro. Ce Reply informe explicitement le client que les adresses dans l'IA ne sont plus valides. Dans cette situation, si le serveur n'envoie pas de message Reply, le serveur rejette silencieusement le message Rebind.

Si le serveur découvre que l'une des adresses n'est plus appropriée au lien auquel le client est connecté, le serveur retourne l'adresse au client avec une durée de vie valide de 0.

Si le serveur trouve les adresses de l'IA du client, le serveur doit renvoyer l'IA au client avec de nouvelles durées de vie et des temps T1/T2.

Le serveur construit un message Reply en définissant le champ "message type" à REPLY et en copiant le transaction ID du message Rebind dans le champ transaction ID.

Le serveur doit inclure une option Server Identifier contenant le DUID du serveur et une option Client Identifier du message Rebind dans le message Reply.

Le serveur inclut d'autres options contenant les informations de configuration retournées au client comme décrit dans la section 18.2.

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

Si le serveur reçoit un message Information-request, le client demande des informations de configuration sans assignation d'adresse. Le serveur détermine tous les paramètres de configuration appropriés pour le client selon la politique de configuration du serveur que le serveur reconnaît.

Le serveur construit un message Reply en définissant le champ "message type" à REPLY et en copiant le transaction ID du message Information-request dans le champ transaction ID.

Le serveur doit inclure une option Server Identifier contenant le DUID du serveur dans le message Reply. Si le client a inclus une option Client Identifier dans le message Information-request, le serveur copie cette option dans le message Reply.

Le serveur inclut des options contenant les informations de configuration retournées au client comme décrit dans la section 18.2.

Si le message Information-request reçu du client ne contient pas d'option Client Identifier, le serveur doit répondre avec un message Reply contenant des paramètres de configuration qui ne sont pas déterminés par l'identité du client. Si le serveur choisit de ne pas répondre, le client peut continuer à retransmettre des messages Information-request indéfiniment.

18.2.6. Receipt of Release Messages (Réception de messages Release)

Si le serveur reçoit un message Release en unicast d'un client auquel le serveur n'a pas envoyé l'option Server Unicast, le serveur rejette le message Release et répond avec un message Reply contenant une option de code de statut avec la valeur UseMulticast, une option Server Identifier contenant le DUID du serveur, une option Client Identifier du message client, et aucune autre option.

Lorsqu'un message Release valide est reçu, le serveur examine la validité de l'IA et des adresses dans l'IA. Si l'IA dans le message est dans la liaison du client et que les adresses dans l'IA ont été assignées par le serveur à ces IA, le serveur supprime les adresses de l'IA et rend les adresses disponibles pour assignation à d'autres clients. Le serveur ignore les adresses qui n'ont pas été assignées à l'IA, bien qu'il puisse choisir d'enregistrer une erreur s'il trouve de telles adresses.

Après que toutes les adresses ont été traitées, le serveur génère un message Reply incluant une option de code de statut avec la valeur Success, une option Server Identifier contenant le DUID du serveur, et une option Client Identifier contenant le DUID du client. Pour chaque IA dans le message Release pour laquelle le serveur n'a pas d'informations de liaison, le serveur ajoute une option IA en utilisant l'IAID du message Release et inclut une option de code de statut avec la valeur NoBinding dans l'option IA. L'option IA ne contient pas d'autres options.

Le serveur peut choisir de conserver un enregistrement des adresses assignées et des IA après que les durées de vie valides des adresses ont expiré. Cela permet au serveur de réassigner des adresses précédemment assignées au client.

18.2.7. Receipt of Decline Messages (Réception de messages Decline)

Si le serveur reçoit un message Decline en unicast d'un client auquel le serveur n'a pas envoyé l'option Server Unicast, le serveur rejette le message Decline et répond avec un message Reply contenant une option de code de statut avec la valeur UseMulticast, une option Server Identifier contenant le DUID du serveur, une option Client Identifier du message client, et aucune autre option.

Lorsqu'un message Decline valide est reçu, le serveur examine la validité de l'IA et des adresses dans l'IA. Si l'IA dans le message est dans la liaison du client et que les adresses dans l'IA ont été assignées par le serveur à ces IA, le serveur supprime les adresses de l'IA. Le serveur ignore les adresses qui n'ont pas été assignées à l'IA (bien qu'il puisse choisir d'enregistrer une erreur s'il trouve de telles adresses).

Le client a découvert que l'une des adresses dans le message Decline est déjà utilisée sur ce lien. Par conséquent, le serveur doit marquer les adresses déclinées par le client pour qu'elles ne soient pas assignées à d'autres clients et peut choisir d'informer que les adresses ont été déclinées. La politique locale sur le serveur détermine quand les adresses identifiées dans le message Decline deviennent disponibles pour assignation.

Après que toutes les adresses ont été traitées, le serveur génère un message Reply incluant une option de code de statut avec la valeur Success, une option Server Identifier contenant le DUID du serveur, et une option Client Identifier contenant le DUID du client. Pour chaque IA dans le message Decline pour laquelle le serveur n'a pas d'informations de liaison, le serveur ajoute une option IA en utilisant l'IAID du message Release et inclut une option de code de statut avec la valeur NoBinding dans l'option IA. L'option IA ne contient pas d'autres options.

18.2.8. Transmission of Reply Messages (Transmission de messages Reply)

Si le message original a été reçu directement par le serveur, le serveur unicast le message Reply au client en utilisant l'adresse dans le champ d'adresse source du datagramme IP qui a reçu le message original. Le message Reply doit être unicasté via l'interface sur laquelle le message original a été reçu.

Si le message original a été reçu dans un message Relay-forward, le serveur construit un message Relay-reply contenant le message Reply dans la charge utile de l'option Relay Message (voir section 22.10). 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.