Revision as of 16:56, 13 March 2016 (view source) Panelli (Talk | contribs) ← Older edit		Latest revision as of 10:17, 15 June 2021 (view source) Bstevant (Talk | contribs) m (Bstevant moved page MOOC:Compagnon Act34 to MOOC:Compagnon Act34-s6)
(199 intermediate revisions by 4 users not shown)
Line 4:		Line 4:
	-->		-->
	__NOTOC__		__NOTOC__
−	= Activité 32: Configurer automatiquement les paramètres réseau =	+	= Activité 34 : Contrôler la configuration réseau par DHCPv6 =
		+	{{Approfondissement}}
		+	== Introduction ==
−	== Principe de l'auto-configuration ==	+	L'autoconfiguration "à état" utilise un serveur pour allouer des adresses IPv6 ou des paramètres de configuration à des nœuds IPv6. Elle réduit les efforts de configuration des nœuds IPv6, tout comme l'autoconfiguration "sans état". Elle offre, à la différence de l'autoconfiguration "sans état", une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des équipements du réseau.
−	La précédente activité a présenté le mécanisme de découverte des voisins permettant à une station connectée à un réseau de récupérer automatiquement les adresses des autres stations du même réseau. C'est la même philosophie qui est mise en oeuvre pour permettre la configuration automatique des paramètres d'une interface réseau.	+	Les deux techniques d'auto-configuration, "avec état" et "sans état", ne sont pas exclusives et peuvent coexister dans un même environnement. Un nœud peut, par exemple, obtenir son adresse "unicast globale" par auto-configuration "sans état" et obtenir les informations relatives aux serveurs de noms (DNS) par l'autoconfiguration "avec état".
−	L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus afin de permettre :	+	L'autoconfiguration "avec état" permet :
−	* à l'utilisateur d'avoir une connexion au réseau fonctionnelle dès le branchement de l'interface réseau	+	* d'assigner des adresses IPv6 stables et prédictibles à la demande et de manière contrôlée ;
−	* à l'administrateur de centraliser la configuration sur un seul équipement qui se chargera de les propager aux stations.	+	* de provisionner au préalable les adresses à assigner aux nœuds ;
		+	* d'automatiser le mécanisme d'assignement ;
		+	* de centraliser les configurations.
−	Les informations nécessaires à la configuration d'une interface sont au minimum :	+	Tout le mécanisme d'autoconfiguration "avec état" est bâti sur le modèle client-serveur. Il utilise le protocole DHCPv6 (''Dynamic Host Configuration Protocol for IPv6'').
−	* des informations permettant de déterminer l'adresse IP ou la méthode permettant de l'obtenir	+	<!--
−	* la largeur du préfixe IP du réseau afin de déterminer les adresses IP appartenant au même réseau	+	Dans les deux cas, si le nœud est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS obtenues quand  celles-ci sont incohérentes.
−	* l'adresse de la passerelle à utiliser pour joindre les adresses qui ne sont pas sur ce réseau	+	-->
−	* le serveur de noms à utiliser sur ce réseau	+
−	L'administrateur renseigne les informations communes pour un réseau sur un équipement. Les stations se configurant récupèrent ces informations pour déterminer leur configuration spécifique qui sera appliquée sur l'interface. La connexion au réseau sera alors effective pour l'utilisateur.	+	== Principe de fonctionnement du protocole DHCPv6 ==
−	Ce mécanisme est donc prévu pour les équipements terminaux. Les équipements intermédiaires dans l'infrastructure, comme les routeurs, ne sont pas censés utiliser ce mécanisme et leur configuration est à la charge de l'administrateur.	+	Le RFC 8415 définit le principe de fonctionnement du protocole DHCPv6. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et le format des messages échangés par ces entités.
		+	La mise au point de ce protocole a cependant fait l'objet de nombreux débats au sein du groupe de travail de l'IETF. DHCP est un élément important du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné un déploiement lent.
−	== Mécanismes mis en oeuvre ==	+	=== Présentation générale du protocole DHCPv6 ===
		+	Le protocole DHCPv6 est un protocole de niveau application. Il fonctionne conformément au modèle client-serveur. Il utilise une communication en mode "non connecté", sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (''requestors'').
		+	Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6.
		+	Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.
−	L'auto-configuration se déroule en plusieurs étapes mettant en oeuvre différents mécanismes :	+	===  Communication en DHCPv6 ===
−	* La toute première étape consiste à créer l'adresse lien-local. Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.	+	DHCPv6 utilise le protocole de transport UDP. Les messages UDP sont encapsulés dans des datagrammes IPv6. Les numéros de ports d'écoute utilisés sont 546 pour le client et 547 pour les serveurs ou les relais.
−	* La machine doit ensuite acquérir les informations commune au réseau, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :	+
−	** l'auto-configuration sans état,	+
−	** l'auto-configuration avec état.	+
−	Note: En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.	+
−	* Les informations transmises par le routeur permettent de plus à la station de configurer sa table de routage.	+
−	* Enfin, toujours en fonction de la politique de configuration, la station va récupérer d'autres informations nécessaire à la configuration, dont notamment le serveur de noms.	+
−	=== La création de l'adresse lien-local ===	+	Lorsque le client et le serveur sont sur le même lien, le serveur reçoit la requête du client sur son port 547. Lorsque le client n’est pas sur le même lien que le serveur, un relais reçoit la demande du client sur son port 547. Le relais réexpédie ensuite ce message vers le port 547 du relais suivant ou du serveur.
−	À l'initialisation de son interface, la station construit un identifiant pour l'interface qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse lien-local est donc créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) standardisé pour cet usage.	+
−	L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée, présentée dans l'activité précédente. Si la station détermine l'adresse lien-local n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.	+	Le serveur DHCPv6 envoie ses réponses depuis son port 547. Il les envoie vers le port 546 du client si la remise directe est possible. Sinon, le serveur envoie sa réponse au premier relais du chemin de retour, sur le port 547.
		+
		+	En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6, se faire en point à point ou en multidiffusion pour la découverte des serveurs DHCPv6. IPv6 s'appuie ensuite sur les fonctions de diffusion générale ou sélective du réseau physique sous-jacent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau n'est pas diffusant, il fait par exemple appel à un serveur de diffusion.
−	Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'auto-configuration est achevée.	+	=== Les entités du protocole ===
−	=== La fourniture des paramètres communs au réseau ===	+	Le protocole DHCPv6 utilise quatre entités pour fonctionner : le client, le serveur, le relais et l'interrogateur. L’utilisation de la quatrième entité, l'interrogateur, est facultative.
−	La seconde étape de l'auto-configuration consiste pour la station qui se configure à récupérer les informations communes au réseau qui sont fixées par l'administrateur. Ces informations sont localisées sur le (ou les) routeur(s) du réseau, équipement sous la responsabilité de l'administrateur et qui sera en charge de les propager aux stations.	+	* Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau.
		+	* Le client DHCPv6 est une machine candidate à une connectivité globale IPv6. Il demande des informations de configuration du réseau à un serveur DHCPv6 pour activer cette connectivité. Il est en relation directe (c'est-à-dire qu'il est sur le même lien) soit avec un relais DHCPv6, soit avec le serveur DHCPv6. Il émet des messages DHCPv6 au serveur DHCPv6.
		+	* Les relais sont transparents. Le client ignore l'existence des relais DHCPv6 et a l'impression de communiquer directement avec le serveur DHCPv6. Ce sont des équipements reliés à plusieurs liens. Ils interceptent le trafic des clients DHCPv6 pour l'acheminer vers les serveurs DHCPv6 lorsque ces derniers ne se trouvent pas sur le lien du client. Ils utilisent pour cela des options spécifiques des relais. ''Notez que ni les relais, ni le serveur ne modifient les messages du client. Les relais se contentent de les encapsuler dans une option de message de relais avant de les relayer vers le serveur.''
		+	* Les interrogateurs (''requestors'') [RFC 5007] sont des entités spécifiques. Les administrateurs les utilisent pour demander à un serveur DHCPv6 des informations relatives aux clients. Un administrateur peut ainsi obtenir des informations relatives au bail d’un client ou à la machine qui utilise une adresse à un instant donné, ou encore obtenir les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.
−	La transmission de ces informations est assurée par un échange de messages ICMPv6 :	+	=== Gestion centralisée des ressources allouées ===
−	* un message de sollicitation d'un routeur (Router Solicitation, ICMP <tt>type</tt> 133) envoyé par la station qui se configure	+	Le client, dans la configuration DHCPv6 "sans état" (''stateless''), a configuré ses adresses IPv6 soit de façon manuelle (fichier interface, intervention de l’administrateur), soit à partir d’informations extraites d’annonces de routeurs (autoconfiguration "sans état"). Il a alors besoin, pour communiquer, d'informations supplémentaires telles que l'adresse IPv6 du serveur DNS.
−	* un message d'annonce de routeur (Router Advertisment, ICMP <tt>type</tt> 134) envoyé par le routeur en réponse à la sollicitation d'une station, mais aussi périodiquement sur le réseau.	+
−	[[File:MOOC_Act32_Fig1.png|666px]]	+	Lorsque le serveur DHCPv6 transmet des informations statiques, ces dernières ne nécessitent pas de conserver un état. Elles ne font donc pas l’objet d’un enregistrement dans le fichier des baux du serveur DHCPv6.
−	Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par la station qui se configure afin d'obtenir les informations du routeur. Ce message est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>.	+	Le serveur DHCPv6, dans la configuration "avec état" (''stateful''), alloue une ou plusieurs adresses IPv6 au client. Ces adresses font l’objet d’un contrat de location temporaire : un bail. Il consigne alors ce contrat de location dans un registre spécial enregistré dans une mémoire non volatile : le fichier des baux (''lease file''). Pour cette raison, ce type de configuration est dit "avec état".
−	[[File:MOOC_Act32_Fig2.png|666px]]	+	==Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais ==
−	Le message d'annonce de routeur (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).	+	Un client DHCPv6 utilise le message DHCPv6 SOLICIT pour découvrir les serveurs configurés pour lui fournir des adresses IPv6 ou des paramètres de configuration du réseau. Comme, à priori, le client ignore l'adresse IPv6 du serveur, le client DHCPv6 envoie toujours ce message à l’adresse multicast <tt>FF02::1:2</tt> qui identifie le groupe des serveurs et relais DHCPv6 (''ALL_DHCP_Relay_Agents_And_Servers'').
−	Ce dernier message est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des stations de la présence du (ou des) routeur(s) afin de confirmer le bon fonctionnement de leur connexion.	+	Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE. Ils font une offre au client DHCPv6.
		+	Si plusieurs serveurs DHCPV6 sont disponibles, le client ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. Il émet alors un message REQUEST destiné au serveur choisi. Il envoie ce message à l’adresse de diffusion sélective ''ALL_DHCP_Relay_Agents_And_Servers''.
		+	Tous les serveurs qui ont répondu à la demande du client savent ainsi si leur offre a été retenue ou non. Le serveur dont l'offre à été retenue, et lui seul, retourne un message REPLY au client.  La figure 1 résume les messages DHCPv6 échangés dans ce cas.
−	Ce message contient un ensemble l'information propre au routeur et à la politique de configuration du réseau, puis ensuite un ensemble d'options en fonction de la politique de configuration. Parmi les information propre au routeur, le champ <tt>durée de vie du routeur</tt> donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut.	+	<center>
		+	[[Image:MOOC_dhcp_Fig6.png|400px|center|thumb|Figure 1 : Dialogue entre client et serveur DHCPv6 présents sur le même lien physique.]]
		+	</center>
		+	=== Recherche des serveurs DHCPv6 par le client : fonctionnement de la pile de communication ===
−	Le champ <tt>durée d'accessibilité</tt> indique la durée en millisecondes pendant laquelle une information de ce message contenue dans le cache de la station peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité (<tt>Neighbor Sollicitation</tt>) est émis pour vérifier la pertinence de l'information.	+	Le client DHCPv6 demande au serveur une adresse IPv6 et un certain nombre de paramètres de configuration du réseau. Il fabrique donc un message DHCPv6 SOLICIT. Il émet ensuite ce message DHCPv6 SOLICIT pour découvrir les serveurs DHCPv6 disponibles.
−	Le champ <tt>temporisation de retransmission</tt> donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.	+	Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 (546) pour expédier ce message vers le port UDP destination du serveur (547). Comme, à ce stade, le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de multicast réservée au protocole DHCPv6 comme adresse IPv6 de destination.
−	La politique de configuration, qui doit indiquer à la station qui se configure les mécanismes à utilsier, est définie par 2 bits du message d'annonce de routeur. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes éventuellement reçus en option du même message. Il doit explicitement demander son adresse auprès d'un serveur d'adresses et donc utiliser la configuration avec état de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration sans état doit être utilisé. Le bit <tt>O</tt> (''Other stateful configuration'') mis à 1 indique que la station doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse.	+	UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à la couche IPv6.
−	=== L'auto-configuration sans état de l'adresse IP ===	+	IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Si notre client n’a qu’une interface, celle-ci est associée à la route par défaut. Sinon, le client envoie le message depuis l'interface de réseau associée à la route par défaut. L'adresse IPv6 "source" utilisée dans le datagramme IPv6 est l'adresse locale au lien de cette interface.
−	Le principe de base de l'auto-configuration sans état de l'adresse IP est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par le routeur. Le routeur fournit à la machine les informations sur le préfixe utilisé sur ce réseau au moyen d'une option incluse dans le message d'annonce de routeur.	+	Notez que l'administrateur du réseau définit l'interface de réseau à utiliser par défaut. Il peut effectuer cette configuration au niveau d'une image disque ou encore au niveau d'un fichier de configuration du client DHCPv6.
−	[[File:MOOC_Act32_Fig3.png|666px]]	+	L’adresse de destination est une adresse de diffusion sélective. Elle n’est associée à aucune route spécifique. Le trafic destiné à ce groupe emprunte la route par défaut. L’adresse IPv6 "source" utilisée ici est donc l’adresse locale au lien de cette interface.
−	Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :	+	IPv6 demande ensuite à Ethernet d’expédier ce datagramme. L’adresse IPv6 de diffusion sélective de destination est ensuite associée à l’adresse Ethernet de diffusion sélective spécifique d’IPv6 (selon le mécanisme d'association d'une adresse IPv6 de multicast à une adresse MAC de multicast, tel qu'il est présenté dans l'activité 15 de la séquence 1). Ceci permet d’utiliser, au niveau d'Ethernet, la diffusion sélective et de ne pas recourir, sur le lien, à la diffusion générale ; ce qui dérangerait un nombre potentiellement considérable de machines sur un réseau IPv6.
−	* Le champ <tt>lg.préfixe</tt> indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.	+	== Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==
−	* Le bit <tt>L</tt> indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.	+
−	* Le bit <tt>A</tt> indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.	+
−	* Le bit <tt>R</tt>, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.	+
−	* Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.	+
−	* Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable».	+
−	Pour ces deux champs, une valeur de <tt>0xffffffff</tt> représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.	+	Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le ou les préfixes à y utiliser.
−	* Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.	+
−	* Le champ préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.	+
−	Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient ici du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Pour construire sont adresse, la station est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC ou généré selon un autre principe comme le tirage aléatoire. Profitant de la souplesse offerte par IPv6, la station peut de plus créer autant d'adresses qu'elle souhaite.	+	Le routeur intermédiaire, entre le client et le serveur DHCPv6, doit supporter une fonction relais DHCPv6. Comme DHCPv6 est un nouveau protocole spécifique d’IPv6, il n’a pas de contrainte de compatibilité ascendante. C’est pourquoi le fonctionnement des relais DHCPv6 est différent de celui des relais DHCPv4.
−	Les valeurs de durée préférable et de durée de validité contrôle le cycle de vie des adresses créées. Une fois le temps indiqué par la durée préférable écoulé depuis la réception du message d'annonce d'un routeur, l'adresse créé à partir du préfixe concerné passera de l'état préféré à l'état déprécié. Une fois le temps indiqué par la durée de validité écoulé depuis la réception du message d'annonce d'un routeur, l'adresse passera de l'état préféré ou déprécié à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre par exemple de contrôler l'utilisation par les stations d'adresses construites à partir de certains préfixes.	+	L'activation de la fonction relais DHCPv6 sur le routeur le transforme en relais DHCPv6. Nous ferons un abus de langage en nommant ce routeur "relais DHCPv6" (nous l'avions déjà fait mais sans le dire...). Notez que, pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.
−	=== L'auto-configuration avec état de l'adresse IP ===	+	Un relais DHCPv6 qui reçoit un message DHCPv6 d’un client l'encapsule dans un message DHCPv6 RELAY-FORWARD. Le message du client est inclus dans l'option "message relayé" du message RELAY-FORWARD que le relais envoie ensuite au serveur DHCPV6, soit en utilisant l’adresse de diffusion sélective réservée, et dans ce cas aucune configuration n'est nécessaire, soit en utilisant l’adresse individuelle (unicast) du serveur DHCPv6. L'administrateur du réseau doit, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse, individuelle ou diffusion sélective, utilisé.
−	Cette méthode de configuration d'adresse repose sur la présence d'un serveur d'adresse contenant une base d'adresses IP disponibles sur le réseau, serveur que la station va solliciter en utilisant le protocole DHCPv6, présenté dans l'activité suivante.	+	Lorsque le message DHCPv6 d’un client doit traverser plusieurs relais DHCPv6, chaque relais encapsule le message RELAY-FORWARD reçu du relais précédent dans l'option "message relayé" de son propre message RELAY-FORWARD.
−	Une station recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présent le bit <tt>M</tt> avec pour valeur 1. Mais ce comportement tel que prévu dans les standards n'est pas entièrement mis en oeuvre dans les systèmes d'exploitation actuel, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 à la station, alors que cette information est fournie par le réseau.	+	Chaque relais traversé identifie (adresse globale ou locale au lien), dans son message RELAY-FORWARD, l’interface sur laquelle il a reçu le message du client ou du relais précédent et l’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.
−	=== La configuration de la table de routage ===	+	Notez que le message du client est recopié dans l'option "message relayé" du message RELAY-FORWARD du premier relais DHCPv6 traversé. Si le message traverse plusieurs relais, l'option "message relayé" du relais courant contient le message RELAY-FORWARD du relais précédent.
−	En IPv6 seuls les routeurs utilisent des protocoles de routage pour définir leurs tables de routage. Le routage des autres machines repose sur la notion de route pour le lien et de route par défaut.	+	Lorsque le serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPv6, l'en-tête de ce message contient l'adresse IPv6 du dernier relais. Il saura donc où envoyer son message RELAY-REPLY.
−	La route vers les adresses du même lien est construite à partir des informations présentes dans l'option concernant ce préfixe réseau. En partant du préfixe ainsi que de la longueur du préfixe, la station peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas la passerelle par défaut. Le noeud destinataire étant alors sur le même lien, l'adresse de niveau liaison (par exemple adresse Ethernet) sera récupérée par le protocole de découverte des voisins.	+	Chaque relais intermédiaire procède de la sorte en extrayant le message RELAY-REPLY du relais précédent de l’option "message relayé" du message RELAY-REPLY reçu.
−	La route par défaut, utilisée pour atteindre le reste de l'Internet à travers le routeur du lien, est configurée grâce à l'adresse lien-local contenue dans le champs source du message d'annonce de routeur. L'adresse physique de cet équipement est de plus contenue dans une des options du message. La station émettant un paquet vers une machine à l'extérieur du réseau utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.	+	Le chemin inverse n’est par conséquent pas difficile à construire. Le protocole DHCPv6 peut ainsi faire parvenir la réponse du serveur au client.
−	=== La découverte de la liste de serveurs DNS récursifs ===	+	<center>
−	L'auto-configuration IPv6 sans état, telle que spécifiée par l'IETF dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration avec état. Les spécifications du protocole d'auto-configuration avec état par DHCPv6, ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'était vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).	+	[[Image:MOOC_dhcp_Fig7.png|400px|center|thumb|Figure 2 : Dialogue entre client et serveur DHCPv6 non présents sur le même lien physique.]]
		+	</center>
−	Trois propositions ont ainsi vu le jour dans le cadre des travaux les groupes « ipv6 », « dhc » et « dnsop » de l'IETF. C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.	+	Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie que l'adresse IPv6 allouée n'est pas déjà en service (DAD : détection d'adresse dupliquée). Il configure alors ses interfaces de réseau, et l'utilisateur qui travaille sur le client DHCPv6 peut accéder au réseau.
−	Voici maintenant un résumé des trois propositions :	+	Le processus DHCPv6 client devient alors inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Il se réactive alors pour libérer (''release'') l'adresse IPv6 allouée.
−	* '''Proposition 1 : mécanisme à base de DHCP''' : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646 :	+	== Libération de l'adresse IPv6 par un client DHCPv6 ==
−	** découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;	+	Le processus d'arrêt normal du client DHCPv6, par échange des messages RELEASE / REPLY inclut la libération de l'adresse IPv6 allouée par le serveur.
−	** découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;	+
−	** Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;	+
−	* '''Proposition 2 : mécanisme à base d'annonce de routeur (RA)''': cette proposition, spécifié dans le RFC 6106 et appelé ND RDNSS, apporte un complément à l'auto-configuration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Ce mécanisme est	+
−	* '''Proposition 3, mécanisme à base d'adresses anycast bien connues''' (''Well-known anycast addresses'') : des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et pré-configurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée et n'a pas été reprise dans un autre document de spécification.	+
−	L'information du support des mécanismes DHCPv6 et ND RDNSS dans les différents système d'exploitation est actualisé sur [http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems cette page Wikipedia].	+	La figure 3 ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais :
		+	<center>
		+	[[Image:MOOC_dhcp_Fig9.png|400px|center|thumb|Figure 3 : Libération d'une adresse IPv6 obtenue directement d'un serveur DHCPv6.]]
		+	</center>
−	== Exemple de configuration automatique ==	+	La figure 4 ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais :
−	Nous allons illustrer ici les différentes étapes de l'auto-configuration et les messages échangés entre la station et le routeur du lien.	+	<center>
		+	[[Image:MOOC_dhcp_Fig8.png|400px|center|thumb|Figure 4 : Libération d'une adresse IPv6 obtenue via un relais DHCPv6. ]]
		+	</center>
−	Au préalable au rattachement de la station au réseau, le routeur du lien est configuré avec le préfixe IPv6 à utiliser sur ce lien. La station, à l'activation de l'interface réseau, crée une adresse lien-local provisoire à partir de l'adresse matérielle de celle-ci.	+	== Fonctions des messages du protocole DHCPv6 ==
		+	Cette partie introduit les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur et, d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.
−	[[File:MOOC_Act32_Fig4_0.png|666px]]	+	En général, les messages échangés transportent des identificateurs de transactions et des associations d'identités. Les serveurs DHCPv6 utilisent les identificateurs de transactions pour associer leurs réponses aux demandes correspondantes des clients. L'identificateur de transaction change pour chaque transaction et est globalement unique pour une transaction donnée. Mais les messages associés à une transaction se distinguent notamment par le champ <tt>Type</tt> de l'en-tête DHCPv6.
−	Mais cette adresse est provisoire. Afin de vérifier si cette adresse est unique, la station débute l'algorithme de détection d'adresse dupliquée (DAD), . Comme décrit dans l'activité précédente, elle émet un message de sollicitation d'un voisin à l'adresse multicast sollicité associée à son adresse provisoire. Son adresse de source est indéterminée car son état est encore provisoire pour le moment et ne sert que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ cible.	+	Les associations d'identités permettent aux serveurs et aux clients de s'identifier mutuellement. Elles identifient également les interfaces de réseau concernées par les demandes de paramètres de configuration du réseau des clients ou par les réponses des serveurs. Elles sont également transmises dans des options du protocole DHCPv6.
−	[[File:MOOC_Act32_Fig4_1.png|666px]]	+	=== Messages échangés entre client et serveur ===
		+	Un client utilise le message SOLICIT (champ <tt>Type</tt> = 1) pour localiser les serveurs configurés pour allouer des adresses ou des paramètres de configuration du réseau.
−	Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd	+	Un serveur configuré pour fournir des adresses ou des paramètres de configuration du réseau aux clients annonce sa disponibilité au client DHCPv6 à l'aide d'un message ADVERTISE (champ <tt>Type</tt> = 2).
−	IPv6	+
−	Version : 6 Priorité : 0xf0 Label: 000000	+
−	Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)	+
−	Nombre de sauts : 255 (0x0ff)	+
−	Source : ::	+
−	Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)	+
−	ICMPv6	+
−	Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37	+
−	cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)	+
−	0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00	+	Un client utilise ensuite le message REQUEST (champ <tt>Type</tt> = 3) pour demander des adresses ou des paramètres de configuration au serveur DHCPv6 choisi. Une option ''options demandées'' contient la liste des paramètres de configuration qu’il demande.
−	0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00	+
−	0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00	+
−	0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d	+
−	Si aucune réponse n'est donné à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse lien-local comme unique. Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.	+	Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message SOLICIT ou REQUEST reçu d’un client DCHPv6.
−	Cette première étape terminée, la station possède donc une adresse lien-local lui permettant de communiquer avec les équipements présents sur le même réseau. Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des équipements en dehors du réseau. La station émet pour cela un message de sollicitation de routeur à tous les routeurs du lien en utilisant l'adresse multicast correspondante : <tt>ff02::2</tt>.	+	=== Messages de gestion des ressources allouées ===
		+	Un client utilise le message CONFIRM (champ <tt>Type</tt> = 4) pour indiquer au serveur qui lui a alloué adresses et paramètres de configuration du réseau et que ces paramètres sont adaptés au lien auquel il est raccordé.
−	[[File:MOOC_Act32_Fig4_2.png|666px]]	+	Un client utilise le message RENEW (champ <tt>Type</tt> = 5) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les lui a alloués. Le client utilise ce message à la demande explicite du serveur.
−	Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd	+	Un client utilise le message REBIND (champ <tt>Type</tt> = 6) pour obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur DHCPV6, si le serveur DHCPv6 auquel il s'est adressé pour renouveler le bail de ses adresses et ses paramètres de configuration du réseau ne répond pas à son message RENEW.
−	IPv6	+
−	Version : 6 Priorité : 0xf0 Label: 000000	+	Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message RENEW ou REBIND reçu d’un client.
−	Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)	+
−	Nombre de sauts : 255 (0x0ff)	+	Un client utilise le message RELEASE (champ <tt>Type</tt> = 8) pour indiquer au serveur DHCPv6 qu'il libère des adresses IPv6.
−	Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)	+
−	Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)	+	Un client utilise le message DECLINE (champ <tt>Type</tt> = 9) pour signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client. La DAD (détection d'adresses dupliquées) d'IPv6 peut, par exemple, fournir cette information.
−	ICMPv6	+
−	Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e	+	Notez que la détection d’adresses dupliquées incombe toujours au client DHCPv6. En effet, le serveur DHCPv6 ne peut effectuer la DAD que lorsqu’il se trouve sur le même réseau que son client, ce qui n’est pas toujours le cas. Or, la DAD n’est possible que sur un lien auquel on est connecté.
−	Option :	+
−	Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d	+	Un serveur utilise le message RECONFIGURE (champ <tt>Type</tt> = 10) pour signaler au client qu'il a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise en particulier si le client doit utiliser le message RENEW ou REBIND.
		+
		+	Un client utilise le message INFORMATION-REQUEST (champ <tt>Type</tt> = 11) pour demander au serveur des paramètres de configuration du réseau, sans demander d’adresse.
		+
		+	=== Messages échangés entre relais et serveur===
		+
		+	Un relais DHCPv6 utilise le message RELAY-FORWARD (champ <tt>Type</tt> = 12) pour relayer des messages DHCPv6 vers un serveur DHCPv6. Le message relayé est soit le message DHCPv6 du client, soit le message RELAY-FORWARD du relais précédent (sur le chemin reliant le client au serveur DHCPv6). Un relais DHCPv6 ne modifie jamais le message d'un client.
		+
		+	Le message du client DHCPv6 est relayé, sans être modifié, dans une option ''message relayé'' du message RELAY-FORWARD du premier relais rencontré sur le chemin reliant le client au serveur DHCPv6.
		+
		+	Un serveur DHCPv6 utilise le message RELAY-REPLY (champ <tt>Type</tt> = 13) pour envoyer un message à un client, via un relais.
		+
		+	Chaque relais qui reçoit un message RELAY-REPLY extrait le message contenu dans l'option "message relayé" et le réexpédie vers le client. Seul le contenu de l'option "message relayé" est donc transmis vers le client.
		+
		+	Le dernier relais extrait le message REPLY destiné au client et contenu dans l'option "message relayé" de ce message RELAY-REPLY pour le lui remettre. Ici encore, le message du client reste inchangé.
		+
		+	=== Tableau récapitulatif des messages DHCPv6 ===
		+	Le tableau ci-dessous résume le nom, le type, l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.
		+
		+	{|
		+	|+'''Message DHCPv6'''
		+	! Type || || Emetteur || Fonction
		+	|-style="background:silver"
		+	| '''SOLICIT'''
		+	|| 1
		+	|| Client
		+	|| Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration .
		+	|-
		+	| '''ADVERTISE'''
		+	|| 2
		+	|| Serveur
		+	|| Annoncer la disponibilité du serveur DHCPv6.
		+	|-style="background:silver"
		+	| '''REQUEST'''
		+	|| 3
		+	|| Client
		+	|| Demander des adresses ou des paramètres de configuration au serveur choisi.
		+	|-
		+	| '''CONFIRM'''
		+	|| 4
		+	|| Client
		+	|| Indiquer au serveur qui a alloué adresses et paramètres de configuration que ces paramètres sont adaptés au lien auquel le client est raccordé.
		+	|-style="background:silver"
		+	| '''RENEW'''
		+	|| 5
		+	|| Client
		+	|| Prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
		+	|-
		+	| '''REBIND'''
		+	|| 6
		+	|| Client
		+	|| Obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur en cas de non réponse au message RENEW.
		+	|-style="background:silver"
		+	| '''REPLY'''
		+	|| 7
		+	|| Serveur
		+	|| Répondre à un message SOLICIT, REQUEST, REBIND, RELEASE reçu d'un client.
		+	|-
		+	| '''RELEASE'''
		+	|| 8
		+	|| Client
		+	|| Indiquer au serveur que le client n'utilise plus des adresses IPv6.
		+	|-style="background:silver"
		+	| '''DECLINE'''
		+	|| 9
		+	|| Client
		+	|| Signaler au serveur qu'une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
		+	|-
		+	| '''RECONFIGURE'''
		+	|| 10
		+	|| Serveur
		+	|| Signaler au client que le serveur a de nouveaux paramètres ou les a actualisés.
		+	|-style="background:silver"
		+	| '''INFORMATION-REQUEST'''
		+	|| 11
		+	|| Client
		+	|| Demander des paramètres de configuration au serveur, sans demander d'adresse.
		+	|-
		+	| '''RELAY-FORWARD'''
		+	|| 12
		+	|| Relais
		+	|| Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6 ou du relais précédent ) est placé dans une option de ce message RELAY-FORW.
		+	|-style="background:silver"
		+	| '''RELAY-REPLY'''
		+	|| 13
		+	|| Serveur
		+	|| Envoyer, depuis un serveur, un message à un client via un relais . Le relais extrait le message destiné au client ou au relais suivant contenu dans l'option "message relayé" de ce message pour le lui remettre.
		+	|}
		+
		+	=== Extension du protocole DHCPv6 [RFC 6422] ===
		+	Notez qu'un mécanisme d'option de relais spécifique permet qu'un relais DHCPv6 communique des paramètres de configuration susceptibles d'intéresser un client DHCPv6 et dont il a connaissance au serveur DHCPv6.
		+
		+	Le serveur DHCPv6 peut ensuite décider ou non, en fonction de la politique définie par l'administrateur du réseau, de communiquer au client tout ou partie des paramètres de configuration du réseau spécifiques issus du relais.
		+
		+	== Structure des messages DHCPv6 ==
		+
		+	Le document RFC 8415 décrit l'ensemble des éléments du protocole DHCPv6. À l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut donc changer et évoluer rapidement, sans impacter les mécanismes de cet échange. Cette séparation assure la stabilité et l'extensibilité du protocole.
		+
		+	La structure des unités de données du protocole reprend ce découpage : un en-tête de taille fixe pour les informations du protocole lui-même et une charge utile transportée dans des champs d'option pour les informations applicatives.
		+
		+	Pour étendre le protocole, il suffit de définir de nouvelles options et de concevoir leur traitement, en émission et en réception. Les options utilisables par DHCPv6 sont référencées dans un registre maintenu par l'IANA<ref>IANA. Protocol Registries [http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Dynamic Host Configuration Protocol for IPv6 (DHCPv6)]</ref>.
		+	Dans la terminologie DHCPv6, le terme "message" désigne une unité de données du protocole DHCPv6. Chaque type de message DHCPv6 (client-serveur ou relais-serveur) a un format d'en-tête identique. De ce point de vue, DHCPv6 reprend les principes de simplification du processus de développement du protocole qui ont guidé la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP.
		+
		+	=== Structure des messages émis par les serveurs et clients DHCPv6 ===
		+	La structure générale des messages échangés entre client et serveur DHCPv6 est la suivante : un champ <tt>type</tt> ''Type-msg'', un champ <tt>identificateur de transaction</tt> ''ID-transaction'', et une liste variable d’options, ''Option list'' (voir la figure 5).
		+
		+	<center>
		+	[[Image:MOOC_dhcp_Fig1.png|400px|center|thumb|Figure 5 : Format des messages échangés entre clients et serveurs DHCPv6.]]
		+	</center>
		+
		+	<tt>Type-msg</tt> : le champ <tt>type de message</tt> identifie la nature du message DHCPv6. Il est codé sur un octet.
		+
		+	<tt>Id-transaction</tt> : l'identificateur de transaction identifie un échange (question/réponse). Il est spécifique aux messages participant à une transaction, et est globalement unique. Il permet d'associer les réponses aux requêtes correspondantes. En effet, la couche transport UDP ne garantit pas le séquencement des réponses lorsque plusieurs requêtes successives ont été émises à destination d'un serveur. Il est codé sur 3 octets.
		+
		+	<tt>Option list</tt> : la liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, selon la sémantique du message, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.
		+
		+	Pour en savoir plus sur les options, reportez-vous à l’annexe 1 ''Options du protocole DHCPv6'' de cette activité.
		+
		+	=== Structure des messages échangés entre relais et serveur DHCPv6 ===
		+	La figure 6 présente la structure des messages échangés entre relais et serveur.
		+
		+	<center>
		+	[[Image:MOOC_dhcp_Fig2.png|400px|center|thumb|Figure 6 : Format des messages échangés entre relais et serveurs DHVPv6.]]
		+	</center>
		+
		+	Les messages utilisés pour la communication entre serveur et relais sont différents des messages utilisés pour la communication entre client et serveur. Un message RELAY-FORWARD transite d'un relais vers un serveur. Un message RELAY-REPLY transite du serveur vers le client.
		+
		+	<tt>Type-msg</tt> : le type du message identifie le type du message DHCPv6.
		+
		+	<tt>Hop-count</tt> : le nombre de sauts identifie soit le nombre de relais déjà traversés pour atteindre le serveur, soit le nombre de relais restant à traverser pour atteindre le client.
		+
		+	<!--
		+	<tt>Link-address</tt> : l'adresse locale au lien désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).
		+
		+	<tt>Peer-address</tt> : l'adresse du pair est une adresse globale ou locale au site. Elle identifie, pour chaque relais, l'interface du relais côté client. Pour le dernier relais, dans le cas du transit d'un message du serveur vers le client, cette adresse identifie l'interface du relais derrière laquelle se trouve le client.
		+	-->
		+	<tt>Link-address</tt> : l'adresse de lien est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
		+
		+	<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.
		+
		+	Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel des relais s'adresser pour répondre à un client donné. Chacun des relais, lorsqu'il faut en traverser plusieurs pour atteindre le client, sait à qui transmettre le message RELAY-REPLY reçu. Le champ <tt>Peer-address</tt> de ce message contient l'adresse locale au lien du relais suivant ou, pour le dernier relais, l'adresse locale au lien du client. Le dernier relais peut donc envoyer au client la réponse du serveur.
		+
		+	==== Message DHCPv6 RELAY-FORWARD ====
		+
		+	<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 12.
		+
		+	<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais traversés par ce message pour atteindre le serveur.
		+	<!--
		+	<tt>Link-address</tt> : l’adresse locale au lien d’un message RELAY-FORWARD est une adresse globale ou une adresse locale au site que le serveur utilise pour identifier le lien où se trouve le client. C'est l'adresse du relais, du côté du client.
		+
		+	<tt>Peer-address</tt> : l’adresse du pair est l’adresse IPv6 de l'interface depuis laquelle le relais a envoyé le message au serveur. C'est l'adresse du relais du côté du serveur.
		+	-->
		+
		+	<tt>Link-address</tt> : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.
		+
		+	<tt>Peer-address</tt> : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.
		+
		+	<tt>Option list</tt> : la liste d’options de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais.
		+
		+	Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.
		+
		+	==== Message DHCPv6 RELAY-REPLY ====
		+
		+	Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur.
		+
		+	<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 13.
		+
		+	<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais que ce message traversera pour atteindre le client.
		+
		+	<tt>Link-address</tt> et <tt>Peer-address</tt> : les adresses du lien et du pair sont recopiées à partir du message RELAY-FORWARD précédent.
		+
		+	<tt>Option list</tt> : la liste d’options doit obligatoirement contenir une option de message relayé (''Relay Message option''). Cette option transporte la réponse du serveur DHCPv6 destinée au client DHCPv6.
		+
		+	=== Types de DUID : DHCPv6 Unique IDentifier ===
		+
		+	Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP gère une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource sous le contrôle du serveur, celle-ci ne peut pas être utilisée pour identifier un client. Le serveur référence donc le client par un identifiant unique à usage exclusif de DHCP : le DUID (''DHCP Unique Identifier'').
−	0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00	+	Chaque station génère son identifiant. Cet identifiant doit être permanent et avoir une grande durée de vie. Une station peut, par exemple, et à un instant donné, générer un DUID à partir de l'adresse MAC d'une de ses cartes réseau. Elle le conservera alors comme identifiant, même en cas de remplacement ultérieur de cette carte réseau.
−	0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00	+
−	0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|	+
−	0030: 01 01 08 00 20 0a aa 6d	+
		+	Les clients utilisent les DUID pour identifier les serveurs quand ils en ont besoin ; par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 ou des paramètres de configuration du réseau.
		+	Le contenu des DUID n’est pas interprété mais uniquement utilisé pour des comparaisons ou pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.
−	Si un routeur est présent, un message annonce de routeur est reçu par la machine se configurant. Elle y trouve les bits <tt>M</tt>, <tt>O</tt> et les informations sur les préfixes du lien.	+	Le RFC 8415 définit trois types d’identificateurs uniques DHCPv6 (DUID). Les DUID peuvent donc être générés selon trois méthodes, repérées par le champ  <tt>type de DUID</tt> dont les valeurs respectives sont :
		+	* <tt>1</tt> : '''''DUID-LLT''''' ''(Link-Layer address plus Time)'' résultant de la combinaison d'une adresse physique et d'une horodate ;
		+	* <tt>2</tt> : '''''DUID-EN''''' ''(Vendor-assigned unique ID based on Enterprise Number)'' dérivé d'un numéro de constructeur ou d'un numéro unique affecté par un constructeur ;
		+	* <tt>3</tt> : '''''DUID-LL''''' ''(Link-Layer address)'' dérivé de l'adresse MAC d'une interface de réseau.
−	[[File:MOOC_Act32_Fig4_3.png|666px]]	+	Le type de DUID est codé sur 2 octets. Un nombre variable d’octets suit, et constitue l’identificateur. La longueur maximale d’un identificateur est 128 octets.
−	Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd	+	Le DUID est lui-même une structure de données qui, selon le mode de construction, contient des types de valeurs différents ''(la structure détaillée des différents type de DUID est présentée en annexe 3 de cette sequence)''.
−	IPv6	+
−	Version : 6 Priorité : 0xf0 Label: 000000	+
−	Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)	+
−	Nombre de sauts : 255 (0x0ff)	+
−	Source : '''fe80::1800:20ff:fe0c:7a34''' (ganesha, lien-local)	+
−	Desti. : '''ff02::1''' (multicast, tous les noeuds du lien)	+
−	ICMPv6	+
−	Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c	+
−	Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)	+
−	Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)	+
−	Options :	+
−	Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34	+
−	Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)	+
−	Drapeaux : L=1, '''A=1''' Durée de validité : -1, -1 (infinie)	+
−	Préfixe : '''2001:db8:12:3::/64'''	+
−		+
−	0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00	+
−	0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00	+
−	0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70	+
−	0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|	+
−	0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00	+
−	0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00	+
−	Le message annonce de routeurs est émis vers le groupe de tous les noeuds IPv6 du lien. Le drapeau <tt>A</tt> étant positionné, le préfixe annoncé peut alors servir à la construction de l'adresse unicast globale. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse <tt>2001:db8:12:3:a00:20ff:fe0a:aa6d</tt> à partir du préfixe et de l'identifiant d'interface issu de l'adresse MAC. D'autres adresses peuvent être construites à partir des identifiants d'interface aléatoires.	+	=== Association d'identités ===
−	De la même façon que l'unicité de l'adresse lien-local a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse unicast globale construite à partir du préfixe communiqué.	+	Une association d’identités IA (''Identity Association'') permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Ces informations sont enregistrées dans des options de l'association.
−	[[File:MOOC_Act32_Fig4_4.png|666px]]	+	Un client associe au moins une association d’identités, IA, à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.
−	Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse lien-local du routeur comme passerelle par défaut. Elle est désormais capable de communiquer avec des équipements situés au delà de ce routeur. D'autres informations comme notamment le DNS qui peuvent être communiquées dans le message d'annonce de routeur sont elles aussi utilisées pour la configuration de la station.	+	Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du réseau IPv6.
−	[[File:MOOC_Act32_Fig4_5.png|666px]]	+	Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées, T1 et T2, où :
		+	* T1 représente la durée de vie de l‘adresse dans l’état préféré ;
		+	* T2 représente la durée de validité de l’adresse IPv6.
		+
		+	Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 :
		+	* des adresses non temporaires ;
		+	* des adresses temporaires.
		+
		+	==== Allocation des adresses non temporaires ====
		+
		+	Le serveur choisit les adresses d’un client en fonction du lien du client, du DUID du client, des options fournies par le client, et des informations fournies par le relais DHCPv6.
		+
		+	Les adresses allouées font l'objet d'une écriture dans le fichier des baux.
		+
		+	==== Allocation des adresses temporaires ====
		+
		+	DHCPv6 gère les adresses temporaires comme les adresses non temporaires : une association d’identités pour adresse temporaire ne contient au plus qu’une seule adresse temporaire. Ici encore, l'allocation d'adresse fait l'objet d'une écriture dans le fichier des baux.
		+
		+	Le serveur DHCPv6, s'il est configuré pour cela, effectue des mises à jour dynamiques sécurisées du service de noms de domaines.
		+
		+	=== Options du protocole DHCPv6===
		+
		+	Chaque option est codée en format TLV : type, longueur, valeur ; à savoir :
		+	* le type de l'option : un champ <tt>type d'option</tt> identifie chaque option d'un paquet DHCPv6. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurées en plusieurs champs (voir annexe 1 : options du protocole DHCPv6) ;
		+	* la longueur, en octets, du champ <tt>valeur du paramètre</tt> qui suit ;
		+	* le champ <tt>valeur du paramètre de configuration</tt>.
		+
		+	Le champ <tt>type d'option</tt> est toujours codé sur 2 octets. Le champ <tt>longueur</tt> est codé sur 2 octets. Il est toujours présent, même en l'absence de valeur ou pour une information de longueur fixe. Il exclut le champ <tt>type</tt> de l'option.
		+
		+	Le tableau qui suit présente les options du protocole DHCPv6, leur code et leur définition. L’annexe 1 présente leur structure.
		+
		+	{|
		+	|+'''Options de DHCPv6'''
		+	! Désignation || Code || Définition
		+	|-style="background:silver"
		+	|<tt>OPTION_CLIENTID</tt>
		+	||1
		+	||Identification du client
		+	|-
		+	|<tt>OPTION_SERVERID</tt>
		+	||2
		+	||Identification du serveur
		+	|-style="background:silver"
		+	|<tt>OPTION_IA_NA</tt>
		+	||3
		+	||Association d’identités pour les options d’adresse non temporaire
		+	|-
		+	|<tt>OPTION_IA_TA</tt>
		+	||4
		+	||Association d’identités pour les options d’adresse temporaire
		+	|-style="background:silver"
		+	|<tt>OPTION_IAADDR</tt>
		+	||5
		+	||Adresse associée à IA_NA ou IA_TA
		+	|-
		+	|<tt>OPTION_ORO</tt>
		+	||6
		+	||Identifie une liste d’options dans les messages échangés entre un client
		+	|-style="background:silver"
		+	|<tt>OPTION_PREFERENCE</tt>
		+	||7
		+	||Annonce au client la priorité du serveur DHCPv6 et comment gérer cette priorité.
		+	|-
		+	|<tt>OPTION_ELAPSED_TIME</tt>
		+	||8
		+	||Temps écoulé depuis le démarrage d'un échange pour la machine qui tente d’achever sa configuration.
		+	|-style="background:silver"
		+	|<tt>OPTION_RELAY_MSG</tt>
		+	||9
		+	||Transporte un message DHCPv6 relayé dans des messages ''relay-forw'' ou ''relay-repl''
		+	|-
		+	|<tt>OPTION_AUTH</tt>
		+	||11
		+	||Transporte les informations d’authentification de l’identité et du contenu des messages DHCPv6.
		+	|-style="background:silver"
		+	|<tt>OPTION_UNICAST</tt>
		+	||12
		+	||Permet au serveur d'indiquer au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur pour échanger avec lui.
		+	|-
		+	|<tt>OPTION_STATUS_CODE</tt>
		+	||13
		+	||Indique le statut du message DHCPv6 qui transporte cette option.
		+	|-style="background:silver"
		+	|<tt>OPTION_RAPID_COMMIT</tt>
		+	||14
		+	||Permet à un client, dans un message SOLICIT, de demander ce mode de fonctionnement pour réaliser des échanges en deux temps au lieu de quatre. Le serveur doit inclure cette option dans la réponse correspondante (''Solicit reply'').
		+	|-
		+	|<tt>OPTION_USER_CLASS</tt>
		+	||15
		+	||Définit la classe d’utilisateur associée à un utilisateur ou à une application.
		+	|-style="background:silver"
		+	|<tt>OPTION_VENDOR_CLASS</tt>
		+	||16
		+	||Identifie le constructeur du matériel utilisé par le client.
		+	|-
		+	|<tt>OPTION_VENDOR_OPTS</tt>
		+	||17
		+	||Permet que le client et le serveur échangent des informations spécifiques d’un constructeur.
		+	|-style="background:silver"
		+	|<tt>OPTION_INTERFACE_ID</tt>
		+	||18
		+	||Identifie l’interface de réception du message du client DHCPv6.
		+	|-
		+	|<tt>OPTION_RECONF_MSG</tt>
		+	||19
		+	||Indique, dans un message ''reconfiguration'', si le client doit répondre par un message ''renew'' ou ''information-request''.
		+	|-style="background:silver"
		+	|<tt>OPTION_RECONF_ACCEPT</tt>
		+	||20
		+	||Indique à un serveur si le client accepte ou refuse les messages ''reconfigure'' ou annonce à un client qu'il peut ou non accepter les messages ''reconfigure''.
		+	|}
		+
		+	== Délégation de préfixe  à états ==
		+	La délégation de préfixe à états fait intervenir deux routeurs : un routeur délégataire et un routeur demandeur. Le routeur délégataire alloue les préfixes. Le routeur demandeur demande un ou plusieurs préfixes au routeur délégataire.
		+
		+	La délégation de préfixe à états utilise le protocole DHCPv6 pour déléguer les préfixes. Elle définit deux options : une association d'identités pour l'allocation de préfixes (IA_PD) et une option de préfixe d'association d'identités pour la délégation de préfixes (IA_PD Prefix).
		+	Le routeur demandeur émet ses demandes sur l'interface qui donne accès au routeur délégataire.
		+
		+	Le routeur délégataire répond sur l'interface qui donne accès au routeur demandeur. Lorsque ces deux routeurs ne se trouvent pas sur le même réseau, des relais DHCPv6 interviennent, comme dans le cas de l'allocation d'adresses. Leur fonctionnement est inchangé.
		+
		+	La délégation de préfixe à états se fait sans relais lorsque les routeurs délégataire et demandeur sont sur le même lien.
		+
		+	Les options de délégation de préfixe permettent au routeur délégataire de déléguer la gestion d'un ou plusieurs préfixes à un routeur demandeur.
		+
		+	L'association d'identités pour l'allocation de préfixes associe notamment les DUID des routeurs demandeur et délégataire, et les préfixes alloués.
		+	L'option de préfixe d'association d'identités pour la délégation de préfixe transporte un préfixe qu'un routeur délégataire a délégué à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une association d'identités (IA_PD).
		+
		+	Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6.
		+
		+	=== Applications de la délégation de préfixe ===
		+
		+	La délégation de préfixe convient pour des situations où le routeur délégataire ignore la topologie du réseau auquel le routeur demandeur donne accès et n'a pas d'autre information à connaître que l'identité du routeur demandeur pour allouer le préfixe. C'est, par exemple, le cas du routeur d'un FAI (Fournisseur d'Accès à Internet) qui alloue un préfixe au routeur d'accès d'un client (CPE : ''Customer Premise Equipment'', familièrement dénommé ''box'') reliant un réseau interne au réseau du FAI.  La figure 7 présente un exemple où la délégation de préfixe à états est possible.
		+
		+	<center>
		+	[[Image:MOOC_dhcp_Fig10.png|400px|center|thumb|Figure 7 : Exemple de délégation de préfixe à états.]]
		+	</center>
		+
		+	La délégation de préfixe facilite également la renumérotation. Elle permet, par exemple,  d'allouer le préfixe qui servira à générer les nouvelles adresses IPv6.
		+	Les préfixes sont censés avoir une grande durée de vie. En cas de renumérotation, la cohabitation pendant un certain temps de l'ancien et du nouveau préfixe est fort probable. C'est par exemple le cas pour la renumérotation passive présentée ci-dessous.
		+
		+	==== Renumérotation des réseaux ====
		+	La renumérotation peut se faire de deux façons : passive ou active.
		+
		+	===== Renumérotation passive =====
		+	Dans la renumérotation passive, chaque machine du réseau dispose de deux adresses IPv6 : une ancienne et une nouvelle. L'ancienne adresse est utilisée par les communications en cours. Ces communications sont préservées aussi longtemps que nécessaire (RENEW). Par contre, les nouvelles communications sont établies à l'aide de la nouvelle adresse. La renumérotation est terminée lorsque la dernière machine du réseau cesse d'utiliser son ancienne adresse.
		+
		+	===== Renumérotation active =====
		+	Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une ancienne adresse et d'une nouvelle.
		+
		+	Le serveur DHCPv6 force les clients à cesser d'utiliser leur ancienne adresse à une date donnée. Le serveur réduit la durée de vie des anciennes adresses en fonction de la date d'échéance cible.
		+
		+	Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est possible. Toutes les communications utilisant les anciennes adresses sont coupées. Elles sont, en cas de besoin, rétablies en utilisant les nouvelles adresses.
		+
		+	Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines autoconfigurent leurs nouvelles adresses.
		+
		+	Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes d'accès au routeur demandeur et d'accès au réseau qu'il dessert.
		+
		+	Deux autres options [RFC 6603], permettent d'exclure un seul préfixe pour l'affecter au lien qui, sur le routeur demandeur, donne accès au routeur délégataire.
		+
		+	Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne de l'interface qui le relie au routeur délégataire. Il utilise alors deux des options du RFC 6603.
		+	''(l'annexe 4 présente la structure de l'option d'association d'identités pour la délégation de préfixes).''
		+
		+	=== Principe de l'allocation ===
		+
		+	Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT contenant une association d'identités pour l'allocation de préfixes à états, IA_PD.
		+	Le routeur délégataire se comporte comme un serveur DHCPV6. Il alloue les préfixes en fonction de l'identité du routeur demandeur et des options de préfixe indiquées (voir la figure 8).
		+
		+	<center>
		+	[[Image:MOOC_dhcp_Fig13.png|400px|center|thumb|Figure 8 : Allocation de préfixe par un routeur délégataire.]]
		+	</center>
		+
		+	=== Principe de l'allocation de préfixe à états avec relais ===
		+
		+	Le relais encapsule le message SOLICIT du client dans l'option "message relayé" de son message RELAY-FORWARD. Il achemine ensuite ce message vers le serveur.
		+
		+	Le serveur renvoie son message RELAY-REPLY au relais.
		+
		+	Le relais  extrait le message ADVERTISE  de l'option "message relayé" du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans le champ ''Peer-Address'' de l'en-tête du message RELAY-REPLY (voir la figure 9).
		+
		+	<center>
		+	[[Image:MOOC_dhcp_Fig14.png|400px|center|thumb|Figure 9 : Allocation de préfixe par un routeur délégataire en présence d'un relais.]]
		+	</center>
	== Conclusion ==		== Conclusion ==
		+	DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP et fonctionne en mode client-serveur. Les messages échangés transportent l'identité de l'émetteur (DUID), celle du récepteur, ou les deux, en fonction du sens de transmission du message et de l'avancement de l'échange.
−	La configuration automatique des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et facilite donc grandement la vie des administrateurs réseau. La configuration est centralisée sur le routeur du réseau qui devient l'équipement crucial à son bon fonctionnement. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.	+	Ce protocole permet qu'un administrateur centralise et gère simplement les paramètres de configuration du réseau, répercute les changements de configuration à l'initiative du serveur DHCPv6 (renumérotation active), ou au contraire, laisse aux clients la possibilité de les prendre en compte lorsqu'ils le souhaitent (renumérotation passive).
−	Cependant la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.	+	Il fonctionne sans relais lorsque le client et le serveur se trouvent sur le même lien. Il fait intervenir des relais lorsque client et serveur sont sur des liens distincts.
		+
		+	Les relais utilisent des messages spécifiques pour communiquer avec les serveurs DHCPv6. Ils encapsulent les messages relayés dans une option de "message relayé". Ainsi, les messages des clients, ceux des serveurs, ou ceux des relais, ne sont jamais modifiés.
		+
		+	Lorsque les relais disposent d’informations locales, des options spécifiques des messages RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6. Les serveurs DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent alors communiquer tout ou partie de ces informations à leurs clients.
		+
		+	Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options. Ainsi, initialement, ni la délégation de préfixe ni l'exclusion de préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.
		+	<!--
		+	Ceci a impliqué des modifications [RFC 7550] pour clarifier ou préciser la spécification RFC 3315 de DHCPv6 et entraînera prochainement la publication d'une nouvelle version de la spécification du protocole DHCPv6.
		+	-->
	== Références bibliographiques ==		== Références bibliographiques ==
	<references />		<references />
−
	== Pour aller plus loin==		== Pour aller plus loin==
		+	RFC et leur analyse par S. Bortzmeyer :
		+	<!--
		+	* RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]
		+	* RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [http://www.bortzmeyer.org/3633.html Analyse]
		+	-->
		+	* RFC 5007 DHCPv6 Leasequery
		+	* RFC 6422 Relay-Supplied DHCP Options
		+	* RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
		+	<!--* RFC 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options -->
		+	* RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]

---

Latest revision as of 10:17, 15 June 2021

Activité 34 : Contrôler la configuration réseau par DHCPv6

Introduction

L'autoconfiguration "à état" utilise un serveur pour allouer des adresses IPv6 ou des paramètres de configuration à des nœuds IPv6. Elle réduit les efforts de configuration des nœuds IPv6, tout comme l'autoconfiguration "sans état". Elle offre, à la différence de l'autoconfiguration "sans état", une information de configuration plus riche et un meilleur contrôle de l'affectation des paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des équipements du réseau.

Les deux techniques d'auto-configuration, "avec état" et "sans état", ne sont pas exclusives et peuvent coexister dans un même environnement. Un nœud peut, par exemple, obtenir son adresse "unicast globale" par auto-configuration "sans état" et obtenir les informations relatives aux serveurs de noms (DNS) par l'autoconfiguration "avec état".

L'autoconfiguration "avec état" permet :

• d'assigner des adresses IPv6 stables et prédictibles à la demande et de manière contrôlée ;
• de provisionner au préalable les adresses à assigner aux nœuds ;
• d'automatiser le mécanisme d'assignement ;
• de centraliser les configurations.

Tout le mécanisme d'autoconfiguration "avec état" est bâti sur le modèle client-serveur. Il utilise le protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6).

Principe de fonctionnement du protocole DHCPv6

Le RFC 8415 définit le principe de fonctionnement du protocole DHCPv6. Ce document spécifie l'architecture de communication, les principes de fonctionnement de chaque entité et le format des messages échangés par ces entités. La mise au point de ce protocole a cependant fait l'objet de nombreux débats au sein du groupe de travail de l'IETF. DHCP est un élément important du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné un déploiement lent.

Présentation générale du protocole DHCPv6

Le protocole DHCPv6 est un protocole de niveau application. Il fonctionne conformément au modèle client-serveur. Il utilise une communication en mode "non connecté", sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.

Communication en DHCPv6

DHCPv6 utilise le protocole de transport UDP. Les messages UDP sont encapsulés dans des datagrammes IPv6. Les numéros de ports d'écoute utilisés sont 546 pour le client et 547 pour les serveurs ou les relais.

Lorsque le client et le serveur sont sur le même lien, le serveur reçoit la requête du client sur son port 547. Lorsque le client n’est pas sur le même lien que le serveur, un relais reçoit la demande du client sur son port 547. Le relais réexpédie ensuite ce message vers le port 547 du relais suivant ou du serveur.

Le serveur DHCPv6 envoie ses réponses depuis son port 547. Il les envoie vers le port 546 du client si la remise directe est possible. Sinon, le serveur envoie sa réponse au premier relais du chemin de retour, sur le port 547.

En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6, se faire en point à point ou en multidiffusion pour la découverte des serveurs DHCPv6. IPv6 s'appuie ensuite sur les fonctions de diffusion générale ou sélective du réseau physique sous-jacent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau n'est pas diffusant, il fait par exemple appel à un serveur de diffusion.

Les entités du protocole

Le protocole DHCPv6 utilise quatre entités pour fonctionner : le client, le serveur, le relais et l'interrogateur. L’utilisation de la quatrième entité, l'interrogateur, est facultative.

• Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau.
• Le client DHCPv6 est une machine candidate à une connectivité globale IPv6. Il demande des informations de configuration du réseau à un serveur DHCPv6 pour activer cette connectivité. Il est en relation directe (c'est-à-dire qu'il est sur le même lien) soit avec un relais DHCPv6, soit avec le serveur DHCPv6. Il émet des messages DHCPv6 au serveur DHCPv6.
• Les relais sont transparents. Le client ignore l'existence des relais DHCPv6 et a l'impression de communiquer directement avec le serveur DHCPv6. Ce sont des équipements reliés à plusieurs liens. Ils interceptent le trafic des clients DHCPv6 pour l'acheminer vers les serveurs DHCPv6 lorsque ces derniers ne se trouvent pas sur le lien du client. Ils utilisent pour cela des options spécifiques des relais. Notez que ni les relais, ni le serveur ne modifient les messages du client. Les relais se contentent de les encapsuler dans une option de message de relais avant de les relayer vers le serveur.
• Les interrogateurs (requestors) [RFC 5007] sont des entités spécifiques. Les administrateurs les utilisent pour demander à un serveur DHCPv6 des informations relatives aux clients. Un administrateur peut ainsi obtenir des informations relatives au bail d’un client ou à la machine qui utilise une adresse à un instant donné, ou encore obtenir les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.

Gestion centralisée des ressources allouées

Le client, dans la configuration DHCPv6 "sans état" (stateless), a configuré ses adresses IPv6 soit de façon manuelle (fichier interface, intervention de l’administrateur), soit à partir d’informations extraites d’annonces de routeurs (autoconfiguration "sans état"). Il a alors besoin, pour communiquer, d'informations supplémentaires telles que l'adresse IPv6 du serveur DNS.

Lorsque le serveur DHCPv6 transmet des informations statiques, ces dernières ne nécessitent pas de conserver un état. Elles ne font donc pas l’objet d’un enregistrement dans le fichier des baux du serveur DHCPv6.

Le serveur DHCPv6, dans la configuration "avec état" (stateful), alloue une ou plusieurs adresses IPv6 au client. Ces adresses font l’objet d’un contrat de location temporaire : un bail. Il consigne alors ce contrat de location dans un registre spécial enregistré dans une mémoire non volatile : le fichier des baux (lease file). Pour cette raison, ce type de configuration est dit "avec état".

Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais

Un client DHCPv6 utilise le message DHCPv6 SOLICIT pour découvrir les serveurs configurés pour lui fournir des adresses IPv6 ou des paramètres de configuration du réseau. Comme, à priori, le client ignore l'adresse IPv6 du serveur, le client DHCPv6 envoie toujours ce message à l’adresse multicast FF02::1:2 qui identifie le groupe des serveurs et relais DHCPv6 (ALL_DHCP_Relay_Agents_And_Servers).

Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE. Ils font une offre au client DHCPv6. Si plusieurs serveurs DHCPV6 sont disponibles, le client ne collecte leurs réponses que pendant un certain temps. Il sélectionne ensuite l'offre qui satisfait le mieux ses besoins. Il émet alors un message REQUEST destiné au serveur choisi. Il envoie ce message à l’adresse de diffusion sélective ALL_DHCP_Relay_Agents_And_Servers. Tous les serveurs qui ont répondu à la demande du client savent ainsi si leur offre a été retenue ou non. Le serveur dont l'offre à été retenue, et lui seul, retourne un message REPLY au client. La figure 1 résume les messages DHCPv6 échangés dans ce cas.

Figure 1 : Dialogue entre client et serveur DHCPv6 présents sur le même lien physique.

Recherche des serveurs DHCPv6 par le client : fonctionnement de la pile de communication

Le client DHCPv6 demande au serveur une adresse IPv6 et un certain nombre de paramètres de configuration du réseau. Il fabrique donc un message DHCPv6 SOLICIT. Il émet ensuite ce message DHCPv6 SOLICIT pour découvrir les serveurs DHCPv6 disponibles.

Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 (546) pour expédier ce message vers le port UDP destination du serveur (547). Comme, à ce stade, le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de multicast réservée au protocole DHCPv6 comme adresse IPv6 de destination.

UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à la couche IPv6.

IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Si notre client n’a qu’une interface, celle-ci est associée à la route par défaut. Sinon, le client envoie le message depuis l'interface de réseau associée à la route par défaut. L'adresse IPv6 "source" utilisée dans le datagramme IPv6 est l'adresse locale au lien de cette interface.

Notez que l'administrateur du réseau définit l'interface de réseau à utiliser par défaut. Il peut effectuer cette configuration au niveau d'une image disque ou encore au niveau d'un fichier de configuration du client DHCPv6.

L’adresse de destination est une adresse de diffusion sélective. Elle n’est associée à aucune route spécifique. Le trafic destiné à ce groupe emprunte la route par défaut. L’adresse IPv6 "source" utilisée ici est donc l’adresse locale au lien de cette interface.

IPv6 demande ensuite à Ethernet d’expédier ce datagramme. L’adresse IPv6 de diffusion sélective de destination est ensuite associée à l’adresse Ethernet de diffusion sélective spécifique d’IPv6 (selon le mécanisme d'association d'une adresse IPv6 de multicast à une adresse MAC de multicast, tel qu'il est présenté dans l'activité 15 de la séquence 1). Ceci permet d’utiliser, au niveau d'Ethernet, la diffusion sélective et de ne pas recourir, sur le lien, à la diffusion générale ; ce qui dérangerait un nombre potentiellement considérable de machines sur un réseau IPv6.

Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6

Lorsque le client se trouve sur un lien différent de celui du serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors allouer des adresses correspondant aux liens du client qu'à condition de pouvoir identifier ces liens, et donc d'identifier le ou les préfixes à y utiliser.

Le routeur intermédiaire, entre le client et le serveur DHCPv6, doit supporter une fonction relais DHCPv6. Comme DHCPv6 est un nouveau protocole spécifique d’IPv6, il n’a pas de contrainte de compatibilité ascendante. C’est pourquoi le fonctionnement des relais DHCPv6 est différent de celui des relais DHCPv4.

L'activation de la fonction relais DHCPv6 sur le routeur le transforme en relais DHCPv6. Nous ferons un abus de langage en nommant ce routeur "relais DHCPv6" (nous l'avions déjà fait mais sans le dire...). Notez que, pour un routeur Linux, par exemple, il suffit de configurer un processus relais DHCPv6 et d'activer ce processus pour que le relais soit opérationnel.

Un relais DHCPv6 qui reçoit un message DHCPv6 d’un client l'encapsule dans un message DHCPv6 RELAY-FORWARD. Le message du client est inclus dans l'option "message relayé" du message RELAY-FORWARD que le relais envoie ensuite au serveur DHCPV6, soit en utilisant l’adresse de diffusion sélective réservée, et dans ce cas aucune configuration n'est nécessaire, soit en utilisant l’adresse individuelle (unicast) du serveur DHCPv6. L'administrateur du réseau doit, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse, individuelle ou diffusion sélective, utilisé.

Lorsque le message DHCPv6 d’un client doit traverser plusieurs relais DHCPv6, chaque relais encapsule le message RELAY-FORWARD reçu du relais précédent dans l'option "message relayé" de son propre message RELAY-FORWARD.

Chaque relais traversé identifie (adresse globale ou locale au lien), dans son message RELAY-FORWARD, l’interface sur laquelle il a reçu le message du client ou du relais précédent et l’adresse locale au lien de l’interface par laquelle il réexpédie son message RELAY-FORWARD au serveur ou au relais suivant.

Notez que le message du client est recopié dans l'option "message relayé" du message RELAY-FORWARD du premier relais DHCPv6 traversé. Si le message traverse plusieurs relais, l'option "message relayé" du relais courant contient le message RELAY-FORWARD du relais précédent.

Lorsque le serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPv6, l'en-tête de ce message contient l'adresse IPv6 du dernier relais. Il saura donc où envoyer son message RELAY-REPLY.

Chaque relais intermédiaire procède de la sorte en extrayant le message RELAY-REPLY du relais précédent de l’option "message relayé" du message RELAY-REPLY reçu.

Le chemin inverse n’est par conséquent pas difficile à construire. Le protocole DHCPv6 peut ainsi faire parvenir la réponse du serveur au client.

Figure 2 : Dialogue entre client et serveur DHCPv6 non présents sur le même lien physique.

Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie que l'adresse IPv6 allouée n'est pas déjà en service (DAD : détection d'adresse dupliquée). Il configure alors ses interfaces de réseau, et l'utilisateur qui travaille sur le client DHCPv6 peut accéder au réseau.

Le processus DHCPv6 client devient alors inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Il se réactive alors pour libérer (release) l'adresse IPv6 allouée.

Libération de l'adresse IPv6 par un client DHCPv6

Le processus d'arrêt normal du client DHCPv6, par échange des messages RELEASE / REPLY inclut la libération de l'adresse IPv6 allouée par le serveur.

La figure 3 ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais :

Figure 3 : Libération d'une adresse IPv6 obtenue directement d'un serveur DHCPv6.

La figure 4 ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais :

Figure 4 : Libération d'une adresse IPv6 obtenue via un relais DHCPv6.

Fonctions des messages du protocole DHCPv6

Cette partie introduit les messages du protocole DHCPv6. Ce protocole distingue deux types de messages : d’une part, les messages échangés entre client et serveur et, d’autre part, les messages échangés entre serveur et relais. Nous les présentons successivement dans cet ordre.

En général, les messages échangés transportent des identificateurs de transactions et des associations d'identités. Les serveurs DHCPv6 utilisent les identificateurs de transactions pour associer leurs réponses aux demandes correspondantes des clients. L'identificateur de transaction change pour chaque transaction et est globalement unique pour une transaction donnée. Mais les messages associés à une transaction se distinguent notamment par le champ Type de l'en-tête DHCPv6.

Les associations d'identités permettent aux serveurs et aux clients de s'identifier mutuellement. Elles identifient également les interfaces de réseau concernées par les demandes de paramètres de configuration du réseau des clients ou par les réponses des serveurs. Elles sont également transmises dans des options du protocole DHCPv6.

Messages échangés entre client et serveur

Un client utilise le message SOLICIT (champ Type = 1) pour localiser les serveurs configurés pour allouer des adresses ou des paramètres de configuration du réseau.

Un serveur configuré pour fournir des adresses ou des paramètres de configuration du réseau aux clients annonce sa disponibilité au client DHCPv6 à l'aide d'un message ADVERTISE (champ Type = 2).

Un client utilise ensuite le message REQUEST (champ Type = 3) pour demander des adresses ou des paramètres de configuration au serveur DHCPv6 choisi. Une option options demandées contient la liste des paramètres de configuration qu’il demande.

Un serveur utilise le message REPLY (champ Type = 7) pour répondre à un message SOLICIT ou REQUEST reçu d’un client DCHPv6.

Messages de gestion des ressources allouées

Un client utilise le message CONFIRM (champ Type = 4) pour indiquer au serveur qui lui a alloué adresses et paramètres de configuration du réseau et que ces paramètres sont adaptés au lien auquel il est raccordé.

Un client utilise le message RENEW (champ Type = 5) pour prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les lui a alloués. Le client utilise ce message à la demande explicite du serveur.

Un client utilise le message REBIND (champ Type = 6) pour obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur DHCPV6, si le serveur DHCPv6 auquel il s'est adressé pour renouveler le bail de ses adresses et ses paramètres de configuration du réseau ne répond pas à son message RENEW.

Un serveur utilise le message REPLY (champ Type = 7) pour répondre à un message RENEW ou REBIND reçu d’un client.

Un client utilise le message RELEASE (champ Type = 8) pour indiquer au serveur DHCPv6 qu'il libère des adresses IPv6.

Un client utilise le message DECLINE (champ Type = 9) pour signaler au serveur qu’une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client. La DAD (détection d'adresses dupliquées) d'IPv6 peut, par exemple, fournir cette information.

Notez que la détection d’adresses dupliquées incombe toujours au client DHCPv6. En effet, le serveur DHCPv6 ne peut effectuer la DAD que lorsqu’il se trouve sur le même réseau que son client, ce qui n’est pas toujours le cas. Or, la DAD n’est possible que sur un lien auquel on est connecté.

Un serveur utilise le message RECONFIGURE (champ Type = 10) pour signaler au client qu'il a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise en particulier si le client doit utiliser le message RENEW ou REBIND.

Un client utilise le message INFORMATION-REQUEST (champ Type = 11) pour demander au serveur des paramètres de configuration du réseau, sans demander d’adresse.

Messages échangés entre relais et serveur

Un relais DHCPv6 utilise le message RELAY-FORWARD (champ Type = 12) pour relayer des messages DHCPv6 vers un serveur DHCPv6. Le message relayé est soit le message DHCPv6 du client, soit le message RELAY-FORWARD du relais précédent (sur le chemin reliant le client au serveur DHCPv6). Un relais DHCPv6 ne modifie jamais le message d'un client.

Le message du client DHCPv6 est relayé, sans être modifié, dans une option message relayé du message RELAY-FORWARD du premier relais rencontré sur le chemin reliant le client au serveur DHCPv6.

Un serveur DHCPv6 utilise le message RELAY-REPLY (champ Type = 13) pour envoyer un message à un client, via un relais.

Chaque relais qui reçoit un message RELAY-REPLY extrait le message contenu dans l'option "message relayé" et le réexpédie vers le client. Seul le contenu de l'option "message relayé" est donc transmis vers le client.

Le dernier relais extrait le message REPLY destiné au client et contenu dans l'option "message relayé" de ce message RELAY-REPLY pour le lui remettre. Ici encore, le message du client reste inchangé.

Tableau récapitulatif des messages DHCPv6

Le tableau ci-dessous résume le nom, le type, l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.

Message DHCPv6

Type		Emetteur	Fonction
SOLICIT	1	Client	Localiser les serveurs configurés pour fournir des adresses ou des paramètres de configuration .
ADVERTISE	2	Serveur	Annoncer la disponibilité du serveur DHCPv6.
REQUEST	3	Client	Demander des adresses ou des paramètres de configuration au serveur choisi.
CONFIRM	4	Client	Indiquer au serveur qui a alloué adresses et paramètres de configuration que ces paramètres sont adaptés au lien auquel le client est raccordé.
RENEW	5	Client	Prolonger le bail de location des adresses et actualiser des paramètres de configuration auprès du serveur qui les a alloués.
REBIND	6	Client	Obtenir un bail de location des adresses et actualiser des paramètres de configuration auprès de tout serveur en cas de non réponse au message RENEW.
REPLY	7	Serveur	Répondre à un message SOLICIT, REQUEST, REBIND, RELEASE reçu d'un client.
RELEASE	8	Client	Indiquer au serveur que le client n'utilise plus des adresses IPv6.
DECLINE	9	Client	Signaler au serveur qu'une ou des adresses allouées par le serveur sont déjà utilisées sur le lien du client.
RECONFIGURE	10	Serveur	Signaler au client que le serveur a de nouveaux paramètres ou les a actualisés.
INFORMATION-REQUEST	11	Client	Demander des paramètres de configuration au serveur, sans demander d'adresse.
RELAY-FORWARD	12	Relais	Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6 ou du relais précédent ) est placé dans une option de ce message RELAY-FORW.
RELAY-REPLY	13	Serveur	Envoyer, depuis un serveur, un message à un client via un relais . Le relais extrait le message destiné au client ou au relais suivant contenu dans l'option "message relayé" de ce message pour le lui remettre.

Extension du protocole DHCPv6 [RFC 6422]

Notez qu'un mécanisme d'option de relais spécifique permet qu'un relais DHCPv6 communique des paramètres de configuration susceptibles d'intéresser un client DHCPv6 et dont il a connaissance au serveur DHCPv6.

Le serveur DHCPv6 peut ensuite décider ou non, en fonction de la politique définie par l'administrateur du réseau, de communiquer au client tout ou partie des paramètres de configuration du réseau spécifiques issus du relais.

Structure des messages DHCPv6

Le document RFC 8415 décrit l'ensemble des éléments du protocole DHCPv6. À l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut donc changer et évoluer rapidement, sans impacter les mécanismes de cet échange. Cette séparation assure la stabilité et l'extensibilité du protocole.

La structure des unités de données du protocole reprend ce découpage : un en-tête de taille fixe pour les informations du protocole lui-même et une charge utile transportée dans des champs d'option pour les informations applicatives.

Pour étendre le protocole, il suffit de définir de nouvelles options et de concevoir leur traitement, en émission et en réception. Les options utilisables par DHCPv6 sont référencées dans un registre maintenu par l'IANA^[1]. Dans la terminologie DHCPv6, le terme "message" désigne une unité de données du protocole DHCPv6. Chaque type de message DHCPv6 (client-serveur ou relais-serveur) a un format d'en-tête identique. De ce point de vue, DHCPv6 reprend les principes de simplification du processus de développement du protocole qui ont guidé la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP.

Structure des messages émis par les serveurs et clients DHCPv6

La structure générale des messages échangés entre client et serveur DHCPv6 est la suivante : un champ type Type-msg, un champ identificateur de transaction ID-transaction, et une liste variable d’options, Option list (voir la figure 5).

Figure 5 : Format des messages échangés entre clients et serveurs DHCPv6.

Type-msg : le champ type de message identifie la nature du message DHCPv6. Il est codé sur un octet.

Id-transaction : l'identificateur de transaction identifie un échange (question/réponse). Il est spécifique aux messages participant à une transaction, et est globalement unique. Il permet d'associer les réponses aux requêtes correspondantes. En effet, la couche transport UDP ne garantit pas le séquencement des réponses lorsque plusieurs requêtes successives ont été émises à destination d'un serveur. Il est codé sur 3 octets.

Option list : la liste des options du message est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, selon la sémantique du message, et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives. Elles transportent soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.

Pour en savoir plus sur les options, reportez-vous à l’annexe 1 Options du protocole DHCPv6 de cette activité.

Structure des messages échangés entre relais et serveur DHCPv6

La figure 6 présente la structure des messages échangés entre relais et serveur.

Figure 6 : Format des messages échangés entre relais et serveurs DHVPv6.

Les messages utilisés pour la communication entre serveur et relais sont différents des messages utilisés pour la communication entre client et serveur. Un message RELAY-FORWARD transite d'un relais vers un serveur. Un message RELAY-REPLY transite du serveur vers le client.

Type-msg : le type du message identifie le type du message DHCPv6.

Hop-count : le nombre de sauts identifie soit le nombre de relais déjà traversés pour atteindre le serveur, soit le nombre de relais restant à traverser pour atteindre le client.

Link-address : l'adresse de lien est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.

Peer-address : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.

Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel des relais s'adresser pour répondre à un client donné. Chacun des relais, lorsqu'il faut en traverser plusieurs pour atteindre le client, sait à qui transmettre le message RELAY-REPLY reçu. Le champ Peer-address de ce message contient l'adresse locale au lien du relais suivant ou, pour le dernier relais, l'adresse locale au lien du client. Le dernier relais peut donc envoyer au client la réponse du serveur.

Message DHCPv6 RELAY-FORWARD

Type-msg : le champ type de ce message vaut 12.

Hop-count : le nombre de sauts indique le nombre de relais traversés par ce message pour atteindre le serveur.

Link-address : l'adresse de lien, est une adresse unicast (globale ou locale) qui sera utilisée par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast (globale ou locale) du relais du coté du client.

Peer-address : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu. Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée comme adresse de destination du paquet contenant le message RELAY-REPLY.

Option list : la liste d’options de ce message contient obligatoirement une option de message relayé (Relay Message Option) et éventuellement d’autres options ajoutées par le relais.

Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.

Message DHCPv6 RELAY-REPLY

Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur.

Type-msg : le champ type de ce message vaut 13.

Hop-count : le nombre de sauts indique le nombre de relais que ce message traversera pour atteindre le client.

Link-address et Peer-address : les adresses du lien et du pair sont recopiées à partir du message RELAY-FORWARD précédent.

Option list : la liste d’options doit obligatoirement contenir une option de message relayé (Relay Message option). Cette option transporte la réponse du serveur DHCPv6 destinée au client DHCPv6.

Types de DUID : DHCPv6 Unique IDentifier

Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP gère une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource sous le contrôle du serveur, celle-ci ne peut pas être utilisée pour identifier un client. Le serveur référence donc le client par un identifiant unique à usage exclusif de DHCP : le DUID (DHCP Unique Identifier).

Chaque station génère son identifiant. Cet identifiant doit être permanent et avoir une grande durée de vie. Une station peut, par exemple, et à un instant donné, générer un DUID à partir de l'adresse MAC d'une de ses cartes réseau. Elle le conservera alors comme identifiant, même en cas de remplacement ultérieur de cette carte réseau.

Les clients utilisent les DUID pour identifier les serveurs quand ils en ont besoin ; par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 ou des paramètres de configuration du réseau. Le contenu des DUID n’est pas interprété mais uniquement utilisé pour des comparaisons ou pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ses interfaces.

Le RFC 8415 définit trois types d’identificateurs uniques DHCPv6 (DUID). Les DUID peuvent donc être générés selon trois méthodes, repérées par le champ type de DUID dont les valeurs respectives sont :

• 1 : DUID-LLT (Link-Layer address plus Time) résultant de la combinaison d'une adresse physique et d'une horodate ;
• 2 : DUID-EN (Vendor-assigned unique ID based on Enterprise Number) dérivé d'un numéro de constructeur ou d'un numéro unique affecté par un constructeur ;
• 3 : DUID-LL (Link-Layer address) dérivé de l'adresse MAC d'une interface de réseau.

Le type de DUID est codé sur 2 octets. Un nombre variable d’octets suit, et constitue l’identificateur. La longueur maximale d’un identificateur est 128 octets.

Le DUID est lui-même une structure de données qui, selon le mode de construction, contient des types de valeurs différents (la structure détaillée des différents type de DUID est présentée en annexe 3 de cette sequence).

Association d'identités

Une association d’identités IA (Identity Association) permet qu’un serveur ou un client identifie, groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un identificateur d’association et des informations de configuration associées. Ces informations sont enregistrées dans des options de l'association.

Un client associe au moins une association d’identités, IA, à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.

Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du réseau IPv6.

Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées, T1 et T2, où :

• T1 représente la durée de vie de l‘adresse dans l’état préféré ;
• T2 représente la durée de validité de l’adresse IPv6.

Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 :

• des adresses non temporaires ;
• des adresses temporaires.

Allocation des adresses non temporaires

Le serveur choisit les adresses d’un client en fonction du lien du client, du DUID du client, des options fournies par le client, et des informations fournies par le relais DHCPv6.

Les adresses allouées font l'objet d'une écriture dans le fichier des baux.

Allocation des adresses temporaires

DHCPv6 gère les adresses temporaires comme les adresses non temporaires : une association d’identités pour adresse temporaire ne contient au plus qu’une seule adresse temporaire. Ici encore, l'allocation d'adresse fait l'objet d'une écriture dans le fichier des baux.

Le serveur DHCPv6, s'il est configuré pour cela, effectue des mises à jour dynamiques sécurisées du service de noms de domaines.

Options du protocole DHCPv6

Chaque option est codée en format TLV : type, longueur, valeur ; à savoir :

• le type de l'option : un champ type d'option identifie chaque option d'un paquet DHCPv6. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurées en plusieurs champs (voir annexe 1 : options du protocole DHCPv6) ;
• la longueur, en octets, du champ valeur du paramètre qui suit ;
• le champ valeur du paramètre de configuration.

Le champ type d'option est toujours codé sur 2 octets. Le champ longueur est codé sur 2 octets. Il est toujours présent, même en l'absence de valeur ou pour une information de longueur fixe. Il exclut le champ type de l'option.

Le tableau qui suit présente les options du protocole DHCPv6, leur code et leur définition. L’annexe 1 présente leur structure.

Options de DHCPv6

Désignation	Code	Définition
OPTION_CLIENTID	1	Identification du client
OPTION_SERVERID	2	Identification du serveur
OPTION_IA_NA	3	Association d’identités pour les options d’adresse non temporaire
OPTION_IA_TA	4	Association d’identités pour les options d’adresse temporaire
OPTION_IAADDR	5	Adresse associée à IA_NA ou IA_TA
OPTION_ORO	6	Identifie une liste d’options dans les messages échangés entre un client
OPTION_PREFERENCE	7	Annonce au client la priorité du serveur DHCPv6 et comment gérer cette priorité.
OPTION_ELAPSED_TIME	8	Temps écoulé depuis le démarrage d'un échange pour la machine qui tente d’achever sa configuration.
OPTION_RELAY_MSG	9	Transporte un message DHCPv6 relayé dans des messages relay-forw ou relay-repl
OPTION_AUTH	11	Transporte les informations d’authentification de l’identité et du contenu des messages DHCPv6.
OPTION_UNICAST	12	Permet au serveur d'indiquer au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur pour échanger avec lui.
OPTION_STATUS_CODE	13	Indique le statut du message DHCPv6 qui transporte cette option.
OPTION_RAPID_COMMIT	14	Permet à un client, dans un message SOLICIT, de demander ce mode de fonctionnement pour réaliser des échanges en deux temps au lieu de quatre. Le serveur doit inclure cette option dans la réponse correspondante (Solicit reply).
OPTION_USER_CLASS	15	Définit la classe d’utilisateur associée à un utilisateur ou à une application.
OPTION_VENDOR_CLASS	16	Identifie le constructeur du matériel utilisé par le client.
OPTION_VENDOR_OPTS	17	Permet que le client et le serveur échangent des informations spécifiques d’un constructeur.
OPTION_INTERFACE_ID	18	Identifie l’interface de réception du message du client DHCPv6.
OPTION_RECONF_MSG	19	Indique, dans un message reconfiguration, si le client doit répondre par un message renew ou information-request.
OPTION_RECONF_ACCEPT	20	Indique à un serveur si le client accepte ou refuse les messages reconfigure ou annonce à un client qu'il peut ou non accepter les messages reconfigure.

Délégation de préfixe à états

La délégation de préfixe à états fait intervenir deux routeurs : un routeur délégataire et un routeur demandeur. Le routeur délégataire alloue les préfixes. Le routeur demandeur demande un ou plusieurs préfixes au routeur délégataire.

La délégation de préfixe à états utilise le protocole DHCPv6 pour déléguer les préfixes. Elle définit deux options : une association d'identités pour l'allocation de préfixes (IA_PD) et une option de préfixe d'association d'identités pour la délégation de préfixes (IA_PD Prefix). Le routeur demandeur émet ses demandes sur l'interface qui donne accès au routeur délégataire.

Le routeur délégataire répond sur l'interface qui donne accès au routeur demandeur. Lorsque ces deux routeurs ne se trouvent pas sur le même réseau, des relais DHCPv6 interviennent, comme dans le cas de l'allocation d'adresses. Leur fonctionnement est inchangé.

La délégation de préfixe à états se fait sans relais lorsque les routeurs délégataire et demandeur sont sur le même lien.

Les options de délégation de préfixe permettent au routeur délégataire de déléguer la gestion d'un ou plusieurs préfixes à un routeur demandeur.

L'association d'identités pour l'allocation de préfixes associe notamment les DUID des routeurs demandeur et délégataire, et les préfixes alloués. L'option de préfixe d'association d'identités pour la délégation de préfixe transporte un préfixe qu'un routeur délégataire a délégué à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une association d'identités (IA_PD).

Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6.

Applications de la délégation de préfixe

La délégation de préfixe convient pour des situations où le routeur délégataire ignore la topologie du réseau auquel le routeur demandeur donne accès et n'a pas d'autre information à connaître que l'identité du routeur demandeur pour allouer le préfixe. C'est, par exemple, le cas du routeur d'un FAI (Fournisseur d'Accès à Internet) qui alloue un préfixe au routeur d'accès d'un client (CPE : Customer Premise Equipment, familièrement dénommé box) reliant un réseau interne au réseau du FAI. La figure 7 présente un exemple où la délégation de préfixe à états est possible.

Figure 7 : Exemple de délégation de préfixe à états.

La délégation de préfixe facilite également la renumérotation. Elle permet, par exemple, d'allouer le préfixe qui servira à générer les nouvelles adresses IPv6. Les préfixes sont censés avoir une grande durée de vie. En cas de renumérotation, la cohabitation pendant un certain temps de l'ancien et du nouveau préfixe est fort probable. C'est par exemple le cas pour la renumérotation passive présentée ci-dessous.

Renumérotation des réseaux

La renumérotation peut se faire de deux façons : passive ou active.

Renumérotation passive

Dans la renumérotation passive, chaque machine du réseau dispose de deux adresses IPv6 : une ancienne et une nouvelle. L'ancienne adresse est utilisée par les communications en cours. Ces communications sont préservées aussi longtemps que nécessaire (RENEW). Par contre, les nouvelles communications sont établies à l'aide de la nouvelle adresse. La renumérotation est terminée lorsque la dernière machine du réseau cesse d'utiliser son ancienne adresse.

Renumérotation active

Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une ancienne adresse et d'une nouvelle.

Le serveur DHCPv6 force les clients à cesser d'utiliser leur ancienne adresse à une date donnée. Le serveur réduit la durée de vie des anciennes adresses en fonction de la date d'échéance cible.

Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est possible. Toutes les communications utilisant les anciennes adresses sont coupées. Elles sont, en cas de besoin, rétablies en utilisant les nouvelles adresses.

Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines autoconfigurent leurs nouvelles adresses.

Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes d'accès au routeur demandeur et d'accès au réseau qu'il dessert.

Deux autres options [RFC 6603], permettent d'exclure un seul préfixe pour l'affecter au lien qui, sur le routeur demandeur, donne accès au routeur délégataire.

Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne de l'interface qui le relie au routeur délégataire. Il utilise alors deux des options du RFC 6603. (l'annexe 4 présente la structure de l'option d'association d'identités pour la délégation de préfixes).

Principe de l'allocation

Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT contenant une association d'identités pour l'allocation de préfixes à états, IA_PD. Le routeur délégataire se comporte comme un serveur DHCPV6. Il alloue les préfixes en fonction de l'identité du routeur demandeur et des options de préfixe indiquées (voir la figure 8).

Figure 8 : Allocation de préfixe par un routeur délégataire.

Principe de l'allocation de préfixe à états avec relais

Le relais encapsule le message SOLICIT du client dans l'option "message relayé" de son message RELAY-FORWARD. Il achemine ensuite ce message vers le serveur.

Le serveur renvoie son message RELAY-REPLY au relais.

Le relais extrait le message ADVERTISE de l'option "message relayé" du message RELAY-REPLY du serveur. Il le transmet ensuite au client. Il identifie l'interface d'accès au client grâce à l'adresse du lien incluse dans le champ Peer-Address de l'en-tête du message RELAY-REPLY (voir la figure 9).

Figure 9 : Allocation de préfixe par un routeur délégataire en présence d'un relais.

Conclusion

DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP et fonctionne en mode client-serveur. Les messages échangés transportent l'identité de l'émetteur (DUID), celle du récepteur, ou les deux, en fonction du sens de transmission du message et de l'avancement de l'échange.

Ce protocole permet qu'un administrateur centralise et gère simplement les paramètres de configuration du réseau, répercute les changements de configuration à l'initiative du serveur DHCPv6 (renumérotation active), ou au contraire, laisse aux clients la possibilité de les prendre en compte lorsqu'ils le souhaitent (renumérotation passive).

Il fonctionne sans relais lorsque le client et le serveur se trouvent sur le même lien. Il fait intervenir des relais lorsque client et serveur sont sur des liens distincts.

Les relais utilisent des messages spécifiques pour communiquer avec les serveurs DHCPv6. Ils encapsulent les messages relayés dans une option de "message relayé". Ainsi, les messages des clients, ceux des serveurs, ou ceux des relais, ne sont jamais modifiés.

Lorsque les relais disposent d’informations locales, des options spécifiques des messages RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6. Les serveurs DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent alors communiquer tout ou partie de ces informations à leurs clients.

Tous les paramètres de configuration du réseau sont transportés dans des options des messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y ajouter de nouvelles options. Ainsi, initialement, ni la délégation de préfixe ni l'exclusion de préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.

Références bibliographiques

1. ↑ IANA. Protocol Registries Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 5007 DHCPv6 Leasequery
• RFC 6422 Relay-Supplied DHCP Options
• RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
• RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Analyse