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

Un client initie un échange de messages avec un ou plusieurs serveurs pour acquérir ou mettre à jour des informations de configuration d'intérêt. Le client peut initier l'échange de configuration dans le cadre du processus de configuration du système d'exploitation, lorsqu'il est requis par la couche applicative, lorsqu'il est requis par la configuration automatique sans état (Stateless Address Autoconfiguration), ou comme requis pour prolonger la durée de vie d'une adresse (messages Renew et Rebind).

18.1. Client Behavior (Comportement du client)

Un client utilise les messages Request, Renew, Rebind, Release et Decline au cours du cycle de vie normal des adresses. Il utilise Confirm pour valider les adresses lorsqu'il a pu se déplacer vers un nouveau lien. Il utilise les messages Information-Request lorsqu'il a besoin d'informations de configuration mais pas d'adresses.

Si le client possède une adresse source d'une portée suffisante qui peut être utilisée par le serveur comme adresse de retour, et que le client a reçu une option Server Unicast (section 22.12) du serveur, le client DEVRAIT envoyer en unicast les messages Request, Renew, Release et Decline au serveur.

DISCUSSION :

L'utilisation de l'unicast peut éviter les délais causés par le relais des messages par les agents de relais, ainsi que la surcharge et les réponses en double des serveurs dues à la remise des messages des clients à plusieurs serveurs. Exiger que le client relaie tous les messages DHCP via un agent de relais permet l'inclusion d'options d'agent de relais dans tous les messages envoyés par le client. Le serveur ne devrait activer l'utilisation de l'unicast que lorsque les options d'agent de 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 IA avec des adresses et obtenir d'autres informations de configuration. Le client inclut une ou plusieurs options IA dans le message Request. Le serveur renvoie ensuite des adresses et d'autres informations sur les IA au client dans des options IA d'un message Reply.

Le client génère un ID de transaction et insère cette valeur dans le champ « transaction-id ».

Le client insère l'identifiant du serveur de destination dans une option Server Identifier.

Le client DOIT inclure une option Client Identifier pour s'identifier auprès du serveur. Le client ajoute les autres options appropriées, y compris une ou plusieurs options IA (si le client demande au serveur de lui attribuer des adresses réseau).

Le client DOIT inclure une option Option Request (voir section 22.7) pour indiquer les options qui intéressent le client. Le client PEUT inclure des options 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) qui indique si le client est disposé ou non à accepter des messages Reconfigure du serveur.

Le client transmet 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 entreprend une action basée sur la politique locale du client. Des exemples d'actions que le client peut entreprendre incluent :

Sélectionner un autre serveur dans une liste de serveurs connus du client ; par exemple, des serveurs ayant répondu avec un message Advertise.
Démarrer le processus de localisation des serveurs décrit dans la section 17.
Mettre fin au 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 pu se déplacer vers un nouveau lien, les préfixes des adresses attribuées aux interfaces sur ce lien peuvent ne plus être appropriés au lien auquel le client est connecté. Des exemples de moments où un client a pu se déplacer vers un nouveau lien incluent :

Le client redémarre.
Le client est connecté physiquement à une connexion câblée.
Le client reprend d'un mode de veille (suspend).
Le client utilisant une technologie sans fil change de point d'accès.

Dans toute situation où un client a pu se déplacer vers un nouveau lien, le client DOIT initier un échange de messages Confirm/Reply. Le client inclut toutes les IA attribuées à l'interface qui ont pu se déplacer vers un nouveau lien, avec les adresses associées à ces IA, dans son message Confirm. Tout serveur qui répond indiquera si ces adresses sont appropriées au lien auquel le client est connecté avec l'état dans le message Reply renvoyé au client.

Le client définit le champ « msg-type » sur 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 auprès du serveur. Le client inclut des options IA pour toutes les IA attribuées à l'interface pour laquelle le message Confirm est envoyé. Les options IA incluent toutes les adresses que le client a actuellement associées à ces IA. Le client DEVRAIT définir les champs T1 et T2 dans toute option IA_NA, et les champs preferred-lifetime et valid-lifetime dans les options IA Address à 0, car le serveur ignorera ces champs.

Le premier message Confirm du client sur l'interface DOIT être retardé d'un délai aléatoire compris entre 0 et CNF_MAX_DELAY. Le client transmet 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 aucune réponse avant la fin du processus de transmission du message, comme décrit dans la section 14, le client DEVRAIT continuer à utiliser les adresses IP éventuelles, en utilisant les dernières durées de vie connues pour ces adresses, et DEVRAIT continuer à utiliser d'autres paramètres de configuration obtenus 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 valide et préférée des adresses associées à une IA, le client envoie un message Renew au serveur depuis lequel le client a obtenu les adresses dans la IA contenant une option IA pour la IA. Le client inclut des options IA Address dans l'option IA pour les adresses associées à la IA. Le serveur détermine de nouvelles durées de vie pour les adresses dans la IA selon la configuration administrative du serveur. Le serveur peut également ajouter de nouvelles adresses à la IA. Le serveur peut retirer des adresses de la IA en fixant les durées de vie préférée et valide de ces adresses à zéro.

Le serveur contrôle le moment où le client contacte le serveur pour prolonger les durées de vie sur les adresses attribuées via les paramètres T1 et T2 attribués à une IA.

Au temps T1 pour une IA, le client initie un échange de messages Renew/Reply pour prolonger les durées de vie sur toutes les adresses de la IA. Le client inclut une option IA avec toutes les adresses actuellement attribuées à la IA dans son message Renew.

Si T1 ou T2 est fixé à 0 par le serveur (pour une IA_NA) ou s'il n'y a pas de temps T1 ou T2 (pour une IA_TA), le client peut envoyer respectivement un message Renew ou Rebind, à la discrétion du client.

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

Le client insère l'identifiant du serveur de destination dans une option Server Identifier.

Le client DOIT inclure une option Client Identifier pour s'identifier auprès du serveur. Le client ajoute les autres options appropriées, y compris une ou plusieurs options IA. Le client DOIT inclure la liste des adresses que le client a actuellement associées aux IA dans le message Renew.

Le client transmet 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), moment auquel 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 pour une IA (qui sera 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 avec toutes les adresses actuellement attribuées à la IA dans son message Rebind.

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

Le client transmet 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 des durées de vie valides de toutes les adresses

L'échange de messages se termine lorsque les durées de vie valides de toutes les adresses attribuées à la IA expirent (voir section 10), moment auquel le client a plusieurs actions alternatives parmi lesquelles choisir ; par exemple :

Le client peut choisir d'utiliser un message Solicit pour localiser un nouveau serveur DHCP et envoyer une Request pour la IA expirée au nouveau serveur.
Le client peut avoir d'autres adresses dans d'autres IA, le client peut donc choisir d'abandonner la IA expirée et d'utiliser les adresses dans les 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 qu'aucune adresse ne lui soit attribuée.

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

Le client DEVRAIT inclure une option Client Identifier pour s'identifier auprès du serveur. Si le client n'inclut pas d'option Client Identifier, le serveur ne sera pas en mesure de renvoyer des options spécifiques au client au client, ou le serveur peut choisir de ne pas répondre du tout au message. Le client DOIT inclure une option Client Identifier si le message Information-request sera authentifié.

Le premier message Information-request du client sur l'interface DOIT être retardé d'un délai aléatoire compris entre 0 et INF_MAX_DELAY. Le client transmet 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, un client envoie un message Release au serveur.

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

Le client insère l'identifiant du serveur ayant alloué la/les adresse(s) dans une option Server Identifier.

Le client DOIT inclure une option Client Identifier pour s'identifier auprès du serveur. Le client inclut des options contenant les IA pour les adresses qu'il libère dans le champ « options ». Les adresses à libérer DOIVENT être incluses dans les IA. Toutes adresses pour les IA que le client souhaite continuer à utiliser NE DEVRAIENT PAS être ajoutées aux IA.

Le client NE DOIT PAS utiliser l'une des adresses qu'il libère comme adresse source dans le message Release ou dans tout message transmis ultérieurement.

Puisque les messages Release peuvent être perdus, le client devrait retransmettre le Release s'il ne reçoit aucun Reply. Cependant, il existe des scénarios où le client pourrait ne pas vouloir attendre le délai de retransmission normal avant d'abandonner (par exemple, lors d'un arrêt). Les implémentations DEVRAIENT retransmettre une ou plusieurs fois, mais PEUVENT choisir de terminer le processus de retransmission plus tôt.

Le client transmet 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 commence le processus d'échange du message Release. Si les adresses sont libérées mais que le Reply d'un serveur DHCP est perdu, le client retransmettra le message Release, et le serveur peut répondre avec un Reply indiquant un état NoBinding. Par conséquent, le client ne traite pas un message Reply avec un état NoBinding dans un échange de messages Release comme indiquant une erreur.

Notez que si le client ne parvient pas à libérer les adresses, chaque adresse attribuée à la 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 adresses qui lui ont été attribuées par un serveur sont déjà utilisées par un autre nœud, le client envoie un message Decline au serveur pour l'informer que l'adresse est suspecte.

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

Le client insère l'identifiant du serveur ayant alloué la/les adresse(s) dans une option Server Identifier.

Le client DOIT inclure une option Client Identifier pour s'identifier auprès du serveur. Le client inclut des options contenant les IA pour les adresses qu'il refuse dans le champ « options ». Les adresses à refuser DOIVENT être incluses dans les IA. Toutes adresses pour les IA que le client souhaite continuer à utiliser ne devraient pas être ajoutées aux IA.

Le client NE DOIT PAS utiliser l'une des adresses qu'il refuse comme adresse source dans le message Decline ou dans tout message transmis ultérieurement.

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

IRT   DEC_TIMEOUT
MRT   0
MRC   DEC_MAX_RC
MRD   0

Si les adresses sont refusées mais que le Reply d'un serveur DHCP est perdu, le client retransmettra le message Decline, et le serveur peut répondre avec un Reply indiquant un état NoBinding. Par conséquent, le client ne traite pas un message Reply avec un état NoBinding dans un échange de messages Decline comme indiquant une erreur.

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

À la réception d'un message Reply valide en réponse à un message Solicit (avec une 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 d'afficher tout code d'état ou message de l'option status code dans le message Reply.

Le client DEVRAIT effectuer la détection d'adresses en double [17] sur chacune des adresses 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 en usage 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 Solicit (avec une option Rapid Commit), Request, Renew ou Rebind, le client met à jour les informations qu'il a enregistrées sur les IA à partir des options IA contenues dans le message Reply :

Enregistre les temps T1 et T2.
Ajoute toutes les nouvelles adresses dans l'option IA à la IA telle qu'enregistrée par le client.
Met à jour les durées de vie pour toutes les adresses dans l'option IA que le client a déjà enregistrées dans la IA.
Ignore toutes les adresses de la IA, telle qu'enregistrée par le client, qui ont une durée de vie valide de 0 dans l'option IA Address.
Laisse inchangées les informations sur les adresses que le client a enregistrées dans la IA mais qui n'étaient pas incluses dans la IA par le serveur.

La gestion des informations de configuration spécifiques est détaillée dans la définition de chaque option dans la section 22.

Si le client reçoit un message Reply avec un Status Code contenant UnspecFail, le serveur indique qu'il n'a pas réussi à 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 DOIT limiter la fréquence à laquelle il retransmet le message et limiter la durée pendant laquelle il le retransmet.

Lorsque le client reçoit un message Reply avec une option Status Code avec la valeur UseMulticast, le client enregistre la réception du message et envoie les messages suivants au serveur via l'interface sur laquelle le message a été reçu en utilisant le multicast. Le client renvoie le message original en utilisant le multicast.

Lorsque le client reçoit un état NotOnLink du serveur en réponse à un message Confirm, le client effectue la sollicitation de serveur DHCP, comme décrit dans la section 17, et la configuration initiée par le client comme décrit dans la section 18. Si le client reçoit des messages Reply qui n'indiquent pas un état NotOnLink, le client peut utiliser les adresses dans la IA et ignorer tout message indiquant un état NotOnLink.

Lorsque le client reçoit un état NotOnLink du serveur en réponse à un message Request, le client peut soit réémettre le Request sans spécifier d'adresse, soit redémarrer le processus de localisation des serveurs DHCP (voir section 17).

Le client examine le code d'état dans chaque IA individuellement. Si le code d'état est NoAddrsAvail, le client n'a reçu aucune adresse utilisable dans la IA et peut choisir d'essayer d'obtenir des adresses pour la IA auprès d'un autre serveur. Le client utilise les adresses et autres informations de toute IA qui ne contient pas d'option Status Code avec le code NoAddrsAvail. Si le client ne reçoit aucune adresse dans aucune des IA, il peut soit essayer un autre serveur (en redémarrant peut-être le processus de localisation des serveurs DHCP), soit utiliser le message Information-request pour obtenir uniquement d'autres informations de configuration.

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

envoie un message Request si la IA contenait une option Status Code avec l'état NoBinding (et n'envoie pas d'autres messages Renew/Rebind)
envoie un Renew/Rebind si la IA n'est pas dans le message Reply
sinon accepte les informations dans la IA

Lorsque le client reçoit un message Reply valide en réponse à un message Release, le client considère l'événement Release comme terminé, indépendamment des options Status Code renvoyées par le serveur.

Lorsque le client reçoit un message Reply valide en réponse à un message Decline, le client considère l'événement Decline comme terminé, indépendamment des options Status Code renvoyées par le serveur.

18.2. Server Behavior (Comportement du serveur)

Pour cette discussion, il est supposé que le serveur a été configuré, de manière spécifique à l'implémentation, avec la configuration d'intérêt pour les clients.

Dans la plupart des cas, le serveur enverra un Reply en réponse à un message du client. Ce message Reply DOIT toujours contenir l'option Server Identifier contenant le DUID du serveur et l'option Client Identifier du message du client si elle était présente.

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

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

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

Lorsque le serveur reçoit un message Request valide, le serveur crée des bindings 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 « msg-type » sur REPLY, et en copiant l'ID de transaction du message Request dans le champ transaction-id.

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

Si le serveur trouve que le préfixe sur une ou plusieurs adresses IP dans toute IA du message du client n'est pas approprié au lien auquel le client est connecté, le serveur DOIT renvoyer la IA au client avec une option Status Code avec la valeur NotOnLink.

Si le serveur ne peut attribuer aucune adresse à une IA dans le message du client, le serveur DOIT inclure la IA dans le message Reply sans adresses dans la IA et avec une option Status Code dans la IA contenant le code d'état NoAddrsAvail.

Pour toute IA à laquelle le serveur peut attribuer des adresses, le serveur inclut la IA avec des adresses et d'autres paramètres de configuration, et enregistre la IA comme un nouveau binding du client.

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

Le serveur inclut d'autres options contenant des informations de configuration à renvoyer au client comme décrit dans la section 18.2.

Si le serveur trouve que le client a inclus une IA dans le message Request pour laquelle le serveur a déjà un binding associant la IA au client, le client a renvoyé un message Request pour lequel il n'a pas reçu de message Reply. Le serveur renvoie soit un message Reply précédemment mis en cache, soit un nouveau message Reply.

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

Lorsque 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 réussissent ce test, le serveur renvoie un état Success. Si l'une des adresses échoue à ce test, le serveur renvoie un état NotOnLink. Si le serveur n'est pas en mesure d'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 avait aucune adresse dans aucune des IA envoyées par le client, le serveur NE DOIT PAS envoyer de réponse au client.

Le serveur ignore les champs T1 et T2 dans les options IA et les champs preferred-lifetime et valid-lifetime dans les options IA Address.

Le serveur construit un message Reply en définissant le champ « msg-type » sur REPLY, et en copiant l'ID de transaction du message Confirm dans le champ transaction-id.

Le serveur DOIT inclure une option Server Identifier contenant le DUID du serveur et l'option Client Identifier du message Confirm dans le message Reply. Le serveur inclut une option Status Code qui indique l'état du message Confirm.

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

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

Lorsque le serveur reçoit un message Renew contenant une option IA d'un client, il localise le binding du client et vérifie que les informations dans la IA du client correspondent aux informations stockées pour ce client.

Si le serveur ne parvient pas à trouver une entrée client pour la IA, le serveur renvoie la IA ne contenant aucune adresse avec une option Status Code définie sur NoBinding dans le message Reply.

Si le serveur trouve que l'une des adresses n'est pas appropriée au lien auquel le client est connecté, le serveur renvoie l'adresse au client avec des durées de vie de 0.

Si le serveur trouve les adresses dans la IA pour le client, alors le serveur renvoie la 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 et les durées de vie des adresses dans les IA qui sont renvoyées au client.

Le serveur construit un message Reply en définissant le champ « msg-type » sur REPLY, et en copiant l'ID de transaction du message Renew dans le champ transaction-id.

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

Le serveur inclut d'autres options contenant des informations de configuration à renvoyer au client comme décrit dans la section 18.2.

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

Lorsque le serveur reçoit un message Rebind contenant une option IA d'un client, il localise le binding du client et vérifie que les informations dans la IA du client correspondent aux informations stockées pour ce client.

Si le serveur ne parvient pas à trouver une entrée client pour la IA et que le serveur détermine que les adresses dans la IA ne sont pas appropriées au lien auquel l'interface du client est connectée selon les informations de configuration explicites du serveur, le serveur PEUT envoyer un message Reply au client contenant la IA du client, avec les durées de vie pour les adresses dans la IA fixées à zéro. Ce Reply constitue une notification explicite au client que les adresses dans la IA ne sont plus valides. Dans cette situation, si le serveur n'envoie pas de message Reply, il ignore silencieusement le message Rebind.

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

Si le serveur trouve les adresses dans la IA pour le client, alors le serveur DEVRAIT renvoyer la 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 « msg-type » sur REPLY, et en copiant l'ID de transaction du message Rebind dans le champ transaction-id.

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

Le serveur inclut d'autres options contenant des informations de configuration à renvoyer au client comme décrit dans la section 18.2.

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

Lorsque le serveur reçoit un message Information-request, le client demande des informations de configuration qui n'incluent pas l'attribution d'aucune adresse. Le serveur détermine tous les paramètres de configuration appropriés pour le client, sur la base des politiques de configuration du serveur connues du serveur.

Le serveur construit un message Reply en définissant le champ « msg-type » sur REPLY, et en copiant l'ID de transaction 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 Identification dans le message Information-request, le serveur copie cette option dans le message Reply.

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

Si le message Information-request reçu du client n'incluait pas d'option Client Identifier, le serveur DEVRAIT répondre avec un message Reply contenant tous les 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 le message Information-request indéfiniment.

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

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

À la réception d'un message Release valide, le serveur examine les IA et les adresses dans les IA pour en vérifier la validité. Si les IA dans le message sont dans un binding pour le client, et que les adresses dans les IA ont été attribuées par le serveur à ces IA, le serveur supprime les adresses des IA et rend les adresses disponibles pour attribution à d'autres clients. Le serveur ignore les adresses non attribuées à la IA, bien qu'il puisse choisir d'enregistrer une erreur.

Après le traitement de toutes les adresses, le serveur génère un message Reply et inclut une option Status Code avec la valeur Success, une option Server Identifier avec le DUID du serveur, et une option Client Identifier avec le DUID du client. Pour chaque IA dans le message Release pour laquelle le serveur n'a pas d'informations de binding, le serveur ajoute une option IA en utilisant l'IAID du message Release, et inclut une option Status Code avec la valeur NoBinding dans l'option IA. Aucune autre option n'est incluse dans l'option IA.

Un serveur peut choisir de conserver un journal des adresses et IA attribuées après l'expiration des durées de vie sur les adresses afin de permettre au serveur de réattribuer les adresses précédemment attribuées à un client.

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

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

À la réception d'un message Decline valide, le serveur examine les IA et les adresses dans les IA pour en vérifier la validité. Si les IA dans le message sont dans un binding pour le client, et que les adresses dans les IA ont été attribuées par le serveur à ces IA, le serveur supprime les adresses des IA. Le serveur ignore les adresses non attribuées à la IA (bien qu'il puisse choisir d'enregistrer une erreur s'il trouve une telle adresse).

Le client a trouvé que les adresses dans les messages Decline sont déjà utilisées sur son lien. Par conséquent, le serveur DEVRAIT marquer les adresses refusées par le client afin que ces adresses ne soient pas attribuées à d'autres clients, et PEUT choisir d'envoyer une notification quedes adresses ont été refusées. La politique locale sur le serveur détermine quand les adresses identifiées dans un message Decline peuvent être rendues disponibles pour attribution.

Après le traitement de toutes les adresses, le serveur génère un message Reply et inclut une option Status Code avec la valeur Success, une option Server Identifier avec le DUID du serveur, et une option Client Identifier avec le DUID du client. Pour chaque IA dans le message Decline pour laquelle le serveur n'a pas d'informations de binding, le serveur ajoute une option IA en utilisant l'IAID du message Release et inclut une option Status Code avec la valeur NoBinding dans l'option IA. Aucune autre option n'est incluse dans l'option IA.

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 envoie en unicast le message Reply directement au client en utilisant l'adresse dans le champ adresse source du datagramme IP dans lequel le message original a été reçu. Le message Reply DOIT être envoyé en 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 avec le message Reply dans la charge utile d'une option Relay Message (voir section 22.10). 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.