5. Echanges client/serveur
Cette section conserve le texte de la RFC relatif a DHCPv6, notamment les echanges de messages, le comportement des relais, les DUID, IA_NA, IA_TA, IA_PD, les options DHCP, l'authentification RKAP, les registres IANA, les exigences normatives et les matrices d'apparition des options en annexe.
Texte original de la RFC
5. Echanges client/serveur
Les clients et les serveurs echangent des messages DHCP au moyen d'UDP
(voir [RFC0768] et [BCP145]). Le client utilise une adresse source
link-local ou des adresses determinees par d'autres mecanismes pour
transmettre et recevoir les messages DHCP.
Un client DHCP envoie tous les messages en utilisant une adresse de
destination multicast reservee et limitee au lien
(All_DHCP_Relay_Agents_and_Servers - ff02::1:2), de sorte que le
client n'a pas besoin d'etre configure avec l'adresse ou les adresses
des serveurs DHCP.
Pour permettre a un client DHCP d'envoyer un message a un serveur DHCP
qui n'est pas rattache au meme lien, un agent relais DHCP sur le lien
du client relaiera les messages entre le client et le serveur. Le
fonctionnement de l'agent relais est transparent pour le client. La
discussion des echanges de messages dans le reste de cette section
omettra la description du relais des messages par les agents relais.
5.1. Echanges client/serveur impliquant deux messages
Lorsqu'un client DHCP n'a pas besoin qu'un serveur DHCP lui attribue
des adresses IP ou des prefixes delegues, le client peut obtenir
d'autres informations de configuration, telles qu'une liste de serveurs
DNS disponibles [RFC3646] ou de serveurs NTP [RFC5908], au moyen d'un
seul echange message/reponse avec un serveur DHCP. Pour obtenir
d'autres informations de configuration, le client envoie d'abord un
message Information-request a l'adresse multicast
All_DHCP_Relay_Agents_and_Servers. Les serveurs repondent par un
message Reply contenant les autres informations de configuration pour
le client.
Un client peut aussi demander au serveur d'accelerer l'attribution
d'adresses et/ou la delegation de prefixes en utilisant un echange a
deux messages au lieu de l'echange normal a quatre messages examine
dans la section suivante. L'attribution acceleree peut etre demandee
par le client, et les serveurs peuvent honorer ou non la demande (voir
Sections 18.3.1 et 21.14 pour plus de details et pour les raisons pour
lesquelles les serveurs peuvent ne pas honorer cette demande). Les
clients peuvent demander ce service accelere dans des environnements ou
il est probable qu'un seul serveur soit disponible sur un lien et ou
l'on ne s'attend pas a ce qu'un second serveur devienne disponible, ou
lorsque l'achevement aussi rapide que possible du processus de
configuration est prioritaire.
Pour demander l'echange accelere a deux messages, le client envoie un
message Solicit a l'adresse multicast
All_DHCP_Relay_Agents_and_Servers en demandant l'attribution
d'adresses et/ou de prefixes delegues ainsi que d'autres informations
de configuration. Ce message inclut une indication (l'option Rapid
Commit; voir Section 21.14) indiquant que le client est dispose a
accepter un message Reply immediat du serveur. Le serveur qui est
dispose a valider immediatement l'attribution d'adresses et/ou de
prefixes delegues au client repond par un message Reply. Les
informations de configuration et les adresses et/ou prefixes delegues
contenus dans le message Reply sont alors immediatement disponibles
pour utilisation par le client.
Chaque adresse ou prefixe delegue attribue au client possede des
preferred et valid lifetimes associees, specifiees par le serveur.
Pour demander une extension des lifetimes attribuees a une adresse ou a
un prefixe delegue, le client envoie un message Renew au serveur. Le
serveur envoie au client un message Reply avec les nouvelles
lifetimes, ce qui permet au client de continuer a utiliser l'adresse ou
le prefixe delegue sans interruption. Si le serveur ne peut pas
etendre la lifetime d'une adresse ou d'un prefixe delegue, il l'indique
en retournant l'adresse ou le prefixe delegue avec des lifetimes de 0.
En meme temps, le serveur peut attribuer d'autres adresses ou prefixes
delegues.
Voir Section 18 pour les descriptions d'echanges supplementaires a
deux messages entre le client et le serveur.
5.2. Echanges client/serveur impliquant quatre messages
Pour demander l'attribution d'une ou plusieurs adresses et/ou de
prefixes delegues, un client localise d'abord un serveur DHCP, puis
demande au serveur l'attribution d'adresses et/ou de prefixes delegues
ainsi que d'autres informations de configuration. Le client envoie un
message Solicit a l'adresse multicast
All_DHCP_Relay_Agents_and_Servers pour trouver les serveurs DHCP
disponibles. Tout serveur capable de satisfaire les exigences du
client repond par un message Advertise. Le client choisit ensuite
l'un des serveurs et lui envoie un message Request demandant le bail
d'adresses et/ou de prefixes delegues ainsi que d'autres informations
de configuration. Le serveur repond par un message Reply contenant les
adresses louees, les prefixes delegues et la configuration.
Comme decrit dans la section precedente, le client peut demander une
extension des lifetimes attribuees aux adresses ou aux prefixes
delegues (il s'agit d'un echange a deux messages).
5.3. Echanges serveur/client
Un serveur qui a precedemment communique avec un client et negocie que
le client ecoute les messages Reconfigure peut envoyer au client un
message Reconfigure pour l'amener a mettre a jour sa configuration en
envoyant un message Information-request, Renew ou Rebind. Les
messages Reconfigure sont authentifies conformement a la Section 20.4.
Le client effectue ensuite l'echange a deux messages comme decrit plus
haut. Cela peut etre utilise pour accelerer les changements de
configuration d'un client, par exemple lorsqu'il faut renumeroter un
reseau (voir [RFC6879] et [RFC9096]).