Revision as of 13:18, 23 June 2015 (view source) Bjoachim (Talk | contribs) (→‎Introduction) ← Older edit		Latest revision as of 09:17, 15 June 2021 (view source) Bstevant (Talk | contribs) m (Bstevant moved page MOOC:Compagnon Act34 to MOOC:Compagnon Act34-s6)
(385 intermediate revisions by 7 users not shown)
Line 1:		Line 1:
		+	<!--
	> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]]		> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]]
	----		----
		+	-->
	__NOTOC__		__NOTOC__
−		+	= Activité 34 : Contrôler la configuration réseau par DHCPv6 =
−	= Le système de nommage (DNS) en IPv6 =	+	{{Approfondissement}}
−		+	== Introduction ==
−	Ce chapitre présente une introduction au système DNS, ses	+
−	spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations	+
−	opérationnelles pour l’intégration d’IPv6.	+
−		+	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.
−	L’introduction présente la problématique à résoudre et les	+
−	principes généraux de fonctionnement de ce service.	+
−	Les spécifications du protocole présentent la résolution des	+
−	noms et la résolution inverse ainsi que les ressources nécessaires pour IPv6.	+
−	Les principes de mise en œuvre du service DNS expliquent	+
−	comment configurer un service DNS.	+
−	Les recommandations opérationnelles pour l’intégration	+
−	d’IPv6 présentent les nouveaux problèmes que pose IPv6 pour le DNS et présente	+
−	les recommandations pratiques pour y faire face.	+
−		+	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".
−	==Introduction ==	+
−	Le système de noms de domaine (DNS : ''Domain Name System'') gère la correspondance entre les noms de machines et	+
−	les adresses IP (IPv4 et/ou IPv6).	+
−		+
−	Aujourd’hui, les utilisateurs utilisent principalement les noms de machines.	+
−	Ces noms sont plus faciles à mémoriser que les adresses, et souvent, reflètent	+
−	la fonction de la machine.	+
−	Ainsi <tt>www.example.com</tt> ou <tt>ftp.example.com</tt> représentent respectivement	+	L'autoconfiguration "avec état" permet :
−	les noms des serveurs Web et FTP de la société example.com.	+	* 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.
−	Une application qui s’exécute sur un équipement, A, et qui souhaite	+	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'').
−	communiquer avec une autre application s'exécutant sur un équipement distant,	+	<!--
−	B, dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette	+	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.
−	adresse, la communication ne peut en général pas avoir lieu : les machines	+	-->
−	utilisent le protocole IP pour communiquer et ce protocole n’utilise que les	+
−	adresses IP.	+
−		+
−	Aux débuts de l'Internet, les adresses IPv4 en usage étaient peu nombreuses.	+
−	Il était donc relativement facile de les stocker dans un fichier centralisé, le	+
−	fichier <tt>hosts.txt</tt> (RFC 608).	+
−	Chaque responsable de site transmettait ses modifications, ajouts et	+	== Principe de fonctionnement du protocole DHCPv6 ==
−	suppressions à un centre de gestion chargé de mettre à jour le fichier central.	+
−	Chacun de ces responsables pouvait alors télécharger ce fichier, via FTP par	+	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.
−	exemple, pour mettre à jour les informations de nommage stockées localement (par	+	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.
−	exemple, le fichier <tt>/etc/hosts</tt> pour les systèmes Unix). Un équipement disposant localement d’une version à	+
−	jour du fichier de nommage pouvait ainsi communiquer avec toutes les machines	+
−	connues dans ce fichier.	+
−	Dès le début des années 80, la croissance exponentielle du nombre d'adresses	+	=== Présentation générale du protocole DHCPv6 ===
−	IP utilisées et le besoin de plus en plus fréquent de renuméroter les	+	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'').
−	équipements ont rendu la mise à jour et la mémorisation de ces adresses de plus	+	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.
−	en plus difficile, voire impossible dans des délais raisonnables.	+	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.
−	Paul Mockapetris, de l'Université de Californie, a	+	===  Communication en DHCPv6 ===
−	conçu le système des noms de domaine (DNS) en 1983. Il en a écrit la première	+	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.
−	mise en œuvre, à la demande de Jon Postel.	+
−	Le DNS est initialement un service de résolution, de mise à jour et	+	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.
−	d’enregistrement des correspondances nom-adresse. Il fournit aux utilisateurs	+
−	l’adresse IP associée à un nom de domaine, et ce, quelle que soit la	+
−	localisation de ceux-ci. De plus, il distribue la responsabilité de la mise à	+
−	jour des correspondances nom adresse sur chaque site et met en place un système	+
−	coopératif d’accès aux informations de nommage.	+
−	Petit à petit, le DNS s'est imposé comme étant une infrastructure pour	+	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.
−	l'ensemble des applications TCP/IP classiques comme le mail, le web, le	+
−	transfert de fichier et la connexion à distance. Ce système est donc : hiérarchique,	+
−	réparti, robuste et extensible.	+
−	'''Hiérarchique'''. Le	+	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.
−	système de noms de domaine, pour garantir l’unicité des noms utilise un système	+
−	de nommage hiérarchique. Le nommage hiérarchique utilise une structure d'arbre.	+
−	un arbre est un graphe sans cycle, c'est-à-dire un	+
−	ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin	+
−	reliant la racine de l’arbre à une feuille. Un arbre, à son plus haut niveau se	+
−	compose d’une racine et d’un ensemble de nœud	+
−	« fils ». Chaque fils, dans l’arbre, est relié à son père par un arc.	+
−	Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu’aux feuilles de l’arbre. Une feuille est un nœud qui n’a pas de fils.	+
−	Le nommage hiérarchique associe un nom à chaque nœud d’un	+	=== Les entités du protocole ===
−	arbre : l’arbre de nommage. Le nom d’un domaine est alors défini comme la	+
−	succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de la racine	+
−	à une feuille. Comme un arbre ne contient pas de cycle, chaque feuille n’est	+
−	accessible que par un seul chemin. Par conséquent dans un arbre de nommage, les	+
−	noms sont uniques.	+
−		+
−	Le système de système	+
−	de fichiers d’Unix utilise un arbre de nommage pour garantir l’unicité des noms	+
−	de fichiers. Ainsi le nom de fichier utilisé précédemment <tt>/etc/hosts</tt>.	+
−	Correspond au chemin d’accès à un fichier dans un arbre de nommage. / désigne	+
−	la racine de l’arbre. Le nom etc représente le nom	+
−	d’un répertoire (dossier). Ce répertoire contient des fichiers (ses fils) un de	+
−	ces fils se nomme hosts. La contrainte est évidemment qu’un « père »	+
−	ne peut avoir deux fils portant le même nom !	+
−		+
−	'''Extensibilité'''. La	+
−	structure d'arbre rend le système extensible (''scalable'').	+
−	Pour ajouter un nom, il suffit de d’ajouter, dans l’arborescence (entre la	+
−	racine et les feuilles) un nœud et toute sa descendance et de relier ce nœud à	+
−	un père, en vérifiant que ce père n’a pas deux fils de même nom.	+
−		+
−	Ainsi, si l’on considère une nouvelle société dont le nom de	+
−	domaine est société1.com. Déclarer cette société dans le système de nommage	+
−	revient à ajouter un fils : société1 sous le nœud (père) com, lequel est lui-même fils de « . »	+
−	(point), la racine (sans nom) de l’arbre de nommage.	+
−	'''Réparti''' : Nul	+	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.
−	n’est mieux placé que le responsable du nommage dans un domaine (de	+
−	responsabilité administrative), par exemple celui d’une société pour gérer les	+
−	ajouts, modifications suppressions dans le sous-arbre	+
−	de nommage correspondant à cette société. Chaque responsable du nommage gère le	+
−	nommage dans sa société. Il produit donc une base locale de nommage. Reste	+
−	ensuite à partager ces informations pour les mettre à disposition des	+
−	utilisateurs du réseau. L’idée simple, mais géniale a été de concevoir un	+
−	système client-serveur pour cela. A chaque niveau de la hiérarchie de nommage,	+
−	on associe un serveur de nommage. Chaque serveur gère donc un domaine. Dans ce	+
−	domaine, il peut gérer des sous-domaines, puis finalement gérer des machines.	+
−	Les serveurs sont reliés les uns aux autres par un chaînage	+	* Le serveur DHCPv6 centralise les paramètres de configuration des équipements du réseau.
−	double : chaque père connaît chacun de ses fils, et chaque fils connaît	+	* 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.
−	son père. Les clients du service de nommage se trouvent uniquement au niveau	+	* 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.''
−	des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client	+	* 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.
−	DNS, le resolveur, par machine. Cela signifie que	+
−	toutes les applications qui s’exécutent sur une machine et qui ont besoin de	+
−	résoudre un nom sollicitent le seul et unique client DNS de cette machine, le resolveur.	+
−		+
−	Le client DNS, le resolveur, résout	+
−	un nom de façon très simple : il commence par s’adresser à son père et lui	+
−	demande « Pourrais-tu me fournir l’adresse (ou les adresses) associées à	+
−	ce nom ? ».	+
−		+
−	Soit le père, le serveur de nom du domaine local, dispose de	+
−	la réponse et alors il la fournit au client, soit le père ignore la	+
−	correspondance, et dans ce cas il demande au client de s’adresser au grand-père	+
−	et il fournit au client le nom et l’adresse IP du grand-père. Ce processus se	+
−	répète jusqu’à ce que le client pose la question au serveur racine de l’arborescence.	+
−	Le serveur racine connaît tous ses fils. Il ne dispose localement d’aucune	+	=== Gestion centralisée des ressources allouées ===
−	information de nommage. En revanche , en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. De cette façon, notre client DNS, le resolveur, finit par adresser sa demande au serveur officiel qui gère les correspondances nom adresse pour ce domaine. Ce serveur fournit donc la réponse au client DNS. Ce processus d’interrogation est dit itératif car le client adresse successivement au serveur local, a ses ascendants, jusqu’à poser la question au serveur racine, lequel renvoie à un de ses fils. Ce fils sait lequel de ses fils gère la correspondance ou sait lequel de ses fils gère cette correspondance.	+	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.
−		+
−	Le client DNS finit par poser la question au serveur local	+
−	qui gère officiellement les correspondances nom-adresse pour la machine cible.	+
−	Le client DNS est malin, il enregistre les noms et adresses de tous les	+
−	serveurs consultés dans une mémoire cache. Ceci lui permettra ultérieurement de	+
−	consulter directement un serveur déjà connu. L’efficacité est alors maximale.	+
−		+
−	Si, comme c’est possible dans certains cas, l’arbre de	+
−	nommage est très profond, nous verrons que plusieurs serveurs de noms distincts	+
−	peuvent être regroupés sur une seule machine physique. Ces regroupements	+
−	permettent de réduire la profondeur de la hiérarchie de serveurs, ce qui permet	+
−	d’en accélérer le balayage.	+
−		+
−	'''Robuste'''. Aujourd’hui,	+
−	tout le fonctionnement de l’internet dépend du bon fonctionnement du système de	+
−	nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur	+
−	officiel pour un domaine, le service de nommage devient indisponible si ce	+
−	serveur tombe en panne ou est arrêté.	+
−	C’est pourquoi au moins deux serveurs, situés sur des sites	+	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.
−	géographiquement distincts et indépendants sont nécessaires pour chaque zone de	+
−	nommage (zone DNS). Ceci assure une meilleure disponibilité et un meilleur	+
−	équilibrage de charge.	+
−		+
−	'''Disponibilité'''. La	+
−	probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des	+
−	données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a	+
−	qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de	+
−	fournir le service.	+
−		+
−	'''Equilibrage de charge'''.	+
−	Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple,	+
−	interroger simultanément les deux serveurs pour déterminer lequel est moins	+
−	sollicité et utiliser préférentiellement ses services. En cas de non réponse du	+
−	serveur choisi, le client peut interroger l’autre serveur pour obtenir les	+
−	réponses à ses questions. En pratique, les demandes des différents clients se	+
−	répartissent sur les différents serveurs de noms. Et si deux serveurs ne	+
−	peuvent supporter la charge, il suffit d’en ajouter d’autres.	+
−		+
−	N’oublions pas néanmoins l’administrateur du réseau,	+
−	responsable de la gestion du nommage dans sa zone. Pour lui simplifier la vie,	+
−	le système DNS, distingue deux types de serveurs de noms : primaire et	+
−	secondaires.	+
−	Notez tout d’abord que les serveurs de noms primaire et	+	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".
−	secondaires sont tous des serveurs officiels pour la zone concernée.	+
−	Le serveur primaire est le serveur sur lequel	+	==Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais ==
−	l’administrateur du réseau effectue les mises à jour des informations de	+
−	nommage. Il dispose de fichiers de nommage enregistrés dans une mémoire non	+
−	volatile.	+
−	Les serveurs secondaires sont des serveurs de nommage qui	+	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'').
−	acquièrent leurs informations de nommage auprès du serveur primaire, à l’aide	+
−	d’un protocole de transfert de fichier, par exemple. Un serveur secondaire,	+
−	selon son mode de configuration, peut stocker localement et sur une mémoire non	+
−	volatile, une copie des fichiers de nommage.	+
−	Un serveur secondaire qui enregistre localement et dans une	+	Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE. Ils font une offre au client DHCPv6.
−	mémoire non volatile une copie de la base de nommage peut, d’une part démarrer	+	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''.
−	de façon autonome en cas de panne catastrophique ou non du serveur primaire, et	+	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.
−	d’autre part, peut très facilement être transformé en serveur primaire. Il est	+
−	alors prudent, s’il n’en reste plus, de configurer un ou plusieurs autres	+
−	serveurs secondaires conservant localement une copie des fichiers de nommage…	+
−		+
−	=== Définitions ===	+
−		+
−	Introduisons maintenant trois notions importantes pour	+
−	comprendre le système de nommage et son fonctionnement : domaine,	+
−	sous-domaine et zone.	+
−		+
−	Un '''domaine''' correspond au nœud racine d’un sous-ensemble (sous-arbre)	+
−	de l’arbre de nommage. Un domaine, dans une grande entreprise, par exemple, peut	+
−	comporter plusieurs sous-domaines. Chacun de ces sous-domaines peut, par	+
−	exemple, correspondre à un service de l’entreprise : personnel, finance,	+
−	commercial, production, maintenance, recherche et développement.	+
−		+
−	Si nous supposons que les services production, maintenance,	+
−	et recherche et développement disposent d’informaticiens capable d’y gérer le	+
−	nommage, l’administrateur du nommage de cette société peut déléguer la	+
−	responsabilité du nommage à un informaticien de chacun de ces départements et	+
−	peut gérer le nommage pour les départements incapables de le prendre en	+
−	charge : personnel, finance, commercial.	+
−		+
−	Un '''sous-domaine''' est un sous-ensemble d’un domaine donné.	+
−	Ainsi le domaine société1 est un sous-ensemble du domaine.com. Autrement dit le	+
−	nœud société1 est un fils du nœud com.	+
−	De même, finance est un sous-domaine du domaine société1. Le	+	<center>
−	nom de domaine correspondant serait alors « finance.société1.com. ».	+	[[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 ===
−	Notez que dans cette façon d’écrire les noms on chemine des	+	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.
−	feuilles (finance)de l’arbre de nommage vers sa racine	+
−	(sans nom, représentée par « . »).	+
−	Le responsable du nommage de la société gère une zone qui	+	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.
−	correspond aux sous-domaines : personnel, finance, commercial, et aux informations	+
−	de délégation de responsabilité pour les sous-domaines : production,	+
−	maintenance, recherche et développement.	+
−	Chacun des informaticiens des départements, production,	+	UDP ne gère pas les adresses IPv6. Il transmet donc simplement l’adresse IPv6 de destination du message UDP à la couche IPv6.
−	maintenance, recherche et développement gère les informations de nommage pour son	+
−	sous-domaine. Si aucun d’eux ne délègue le nommage dans sa zone, ils gèrent	+
−	chacun une zone et cette zone correspond dans ce cas à un sous-domaine.	+
−	Une '''zone''' contient tous les noms contenus dans le domaine de	+	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.
−	même nom, mais exclut tous les noms qui se trouvent dans des sous-domaines	+
−	délégués (production, maintenance, recherche et développement, par exemple).	+
−	Une zone peut inclure plusieurs sous-domaines (personnel, finance, commercial)	+
−	et des informations de délégation de zone.	+
−	== Spécifications du service de noms ==	+	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.
−		+
−	Le DNS avait initialement comme objectif premier d'offrir un service de	+
−	résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully'''' Qualified Domain	+
−	Name'') garantissant l'unicité de la conversion du nom (exemple : ns3.nic.fr) en adresses IP et vice-versa.	+
−		+	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.
−	En pratique, système DNS est un service de base de données à grande échelle.	+
−	Il permet, plus généralement, de gérer tout type d’information. Il utilise pour	+
−	cela des enregistrements de ressources (RR : ''Resource Records'')	+
−	spécifiques de chaque type d’information.	+
−		+	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.
−	Chacune des applications d’une machine s’adresse au résolveur (unique) de la	+
−	machine et lui demande des informations associées à des noms de domaines, comme	+
−	des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms	+
−	(enregistrement de type NS).	+
−		+	== Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==
−	Le résolveur de la machine locale interroge successivement chacun des serveurs	+
−	(résolution itérative), jusqu’à ce qu’il s’adresse au serveur officiel du	+
−	domaine concerné.	+
−		+	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 serveur officiel de ce domaine renvoie les informations demandées dans	+
−	des enregistrements de ressource appropriés. Le résolveur mémorise ces	+
−	informations dans une mémoire cache, puis les fournit à l’application qui en a	+
−	fait la demande.	+
−		+	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.
−	Rappelons au passage que pour ces applications, une phase lors de laquelle	+
−	le client DNS local, appelé « stub resolver »,	+
−	interroge son serveur DNS récursif (ou cache) précède la communication .le	+
−	serveur récursif effectue les requêtes itératives nécessaires, en partant de la	+
−	racine de l'arbre DNS, s'il le faut, et renvoie les ressources demandées.	+
−		+	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.
−	Par exemple, pour les machines Unix, le fichier /etc/resolv.conf fournit l'adresse IP d’un ou plusieurs	+
−	serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de	+
−	configuration. Il dispose donc de l’adresse d’un ou plusieurs à interroger, ce	+
−	qui lui permet d’initialiser sa recherche d’information pour le compte des	+
−	applications locales.	+
−		+	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é.
−	Le service de résolution DNS fonctionne au niveau de la couche application	+
−	de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux	+
−	réseaux IPv4.	+
−		+	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.
−	Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16	+
−	octets). Elles peuvent être attribuées automatiquement ou autoconfigurées.	+
−	Elles sont représentées en notation hexadécimale (double) pointée, par exemple,	+
−	2001 :3006 ::beef :cafe :deca :102.	+
−		+	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.
−	Tous ces facteurs ont considérablement réduit les chances qu’un humain	+
−	mémorise ces adresses IPv6. Le service de nommage devient plus que jamais un	+
−	service critique pour le fonctionnement correct des applications TCP/IP	+
−	classiques. Afin de supporter le nouveau schéma d'adressage d'IPv6, deux	+
−	extensions DNS ont été définies ([[RFC 3596]]) : l’enregistrement	+
−	de ressource AAAA et un nouveau sous-domaine : ipv6.arpa.	+
−		+	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.
−	L'enregistrement de ressource AAAA (prononcé « quad	+
−	A ») enregistre les correspondances nom - adresse IPv6. Pour le nommage direct	+
−	(correspondance : nom vers adresse). Ce le code de ce nouveau type vaut 28.	+
−		+	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.
−	Le nouveau sous-domaine ip6.arpa est dédié à la résolution	+
−	DNS inverse en IPv6 (correspondance : adresse IPv6 vers nom). La	+
−	résolution DNS inverse utilise la notion de nibble.	+
−	Un nibble correspond à un chiffre hexadécimal.	+
−		+	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.
−	=== Nommage direct : enregistrement AAAA ===	+
−		+
−	La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4	+
−	est réalisée en associant au nom en question un ou plusieurs enregistrements	+
−	DNS de type A. Chaque	+
−	enregistrement de type A contient la valeur d’une adresse IPv4. Une machine a	+
−	autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multidomiciliée ou routeur, par exemple)	+
−		+	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.
−	De manière analogue, le nouveau type d'enregistrement AAAA défini pour IPv6, établit la	+
−	correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant	+
−	plusieurs adresses IPv6 globales a, en principe, autant d'enregistrements AAAA publiés dans le DNS.	+
−		+	<center>
−	Une requête DNS de type AAAA concernant une machine particulière renvoie	+	[[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.]]
−	dans ce cas tous les enregistrements AAAA	+	</center>
−	publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont	+
−	cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe	+
−	Publication des enregistrements AAAA dans le DNS.	+
−		+	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 format textuel d'un enregistrement AAAA	+
−	tel qu'il apparaît dans le fichier de zone DNS est le suivant :	+
−		+	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.
−	&lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;	+
−		+
−	L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291]]). Par exemple,	+
−	l'adresse IPv6 de la machine ns3.nic.fr	+
−	est publiée dans le fichier de zone nic.fr	+
−	comme suit :	+
−	ns3.nic.fr. IN AAAA 2001:3006:3006:1::1:1	+	== 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.
−	Il est important de noter que toutes les adresses IPv4 et/ou IPv6	+	La figure 3 ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais :
−	correspondant à un équipement donné (c'est le cas d'un réseau configuré en double	+	<center>
−	pile de communication dual-stack), doivent cohabiter	+	[[Image:MOOC_dhcp_Fig9.png|400px|center|thumb|Figure 3 : Libération d'une adresse IPv6 obtenue directement d'un serveur DHCPv6.]]
−	dans le même fichier de zone renseignant le nom de l'équipement en question.	+	</center>
−	Ainsi, les adresses de ns3.nic.fr	+
−	sont publiées dans le fichier de zone nic.fr	+
−	comme suit :	+
−		+	La figure 4 ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais :
−	$ORIGIN nic.fr.	+
−	ns3  IN A    192.134.0.49	+
−	IN AAAA 2001:db8:3006:1::1:1	+
−		+
−	Cependant, il faut rester vigilant avec une telle configuration, puisque	+
−	certains resolveurs recherchent toujours un	+
−	enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le resolver n'a qu'une connection	+
−	IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend	+
−	l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir	+
−	à l’utilisation d’IPv4.	+
−		+	<center>
−	=== Nommage inverse : enregistrement PTR ===	+	[[Image:MOOC_dhcp_Fig8.png|400px|center|thumb|Figure 4 : Libération d'une adresse IPv6 obtenue via un relais DHCPv6. ]]
−		+	</center>
−	L'enregistrement de type PTR,	+
−	est stocké dans le sous-arbre de nommage dédié à la	+
−	résolution inverse (DNS inverse) in-addr.arpa. Pour IPv4, ce sous-domaine établit	+
−	la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). Pour	+
−	IPv6, ce même type d'enregistrement PTR,	+
−	stocké dans le sous-arbre de nommage dédié à la	+
−	résolution inverse (DNS inverse) ip6.arpa,	+
−	met en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.	+
−		+	== Fonctions des messages du protocole DHCPv6 ==
−	Notons au passage qu'auparavant, le [[RFC 1886]], rendu obsolète par le [[RFC 3596]], spécifiait une autre	+	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.
−	arborescence : ip6.int. Cette dernière a été abandonnée en 2006.	+
−		+	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.
−	Un nom de domaine à partir d’une adresse est un problème quasi insoluble.	+
−	Néanmoins une astuce permet de résoudre simplement ce problème. Il suffit de	+
−	présenter les adresses comme des noms. C'est-à-dire que, pour IPv4n, il suffit	+
−	d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une	+
−	adresse par les octets de poids fort, on commence par celle des octets de poids	+
−	faible. Pour IPv6, on considère une adresse IPv4 comme une succession de	+
−	chiffres hexadécimaux (32 par adresse IPv6) séparés par des « . ».	+
−		+	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.
−	Une adresse IPv6 est donc transformée en un nom de domaine	+
−	publié dans le sous-arbre de nommage réservé à la	+
−	résolution inverse pour IPv6 : ip6.arpa	+
−	de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont	+
−	séparés par le caractère `.' et	+
−	concaténés dans l'ordre inverse au suffixe ip6.arpa.	+
−		+	=== Messages échangés entre client et serveur ===
−	Par exemple l'adresse 2001:db8:3006:1::1:1 (adresse de ns3.nic.frdonne le nom de domaine suivant :	+
−	1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa.	+	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.
−	On publie alors dans le DNS inverse l'enregistrement PTR correspondant au nom de domaine	+	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).
−	inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `ns3.nic.fr.'	+
−	En pratique, on procède par délégation de zones inverses afin de répartir	+	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.
−	les enregistrements PTR sur un	+
−	système hiérarchique de serveurs DNS. Les données de résolution inverse se	+
−	trouvent ainsi distribuées sur les différents sites.	+
−	Ainsi, pour un domaine donné, l’administrateur du domaine gère localement la	+	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.
−	base de correspondance nom-adresse et les bases de données de résolution	+
−	inverse, à raison d’une par lien dans le site.	+
−	Soulignons que la délégation DNS inverse suit le schéma classique	+	=== Messages de gestion des ressources allouées ===
−	d'attribution des adresses IP. C’est le même pour IPv4 et IPv6).	+
−		+	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é.
−	=== Schéma de délégation de la gestion des adresses IP ===	+
−		+
−	1) L'IANA délègue (en terme de provision) de grands	+
−	blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle.	+
−		+	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.
−	2) Les RIR provisionnent des blocs d'adresses IPv6 plus	+
−	petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet	+
−	locaux, typiquement des préfixes de longueur 32 bits ou plus courts selon le	+
−	besoin. Notez que dans les régions APNIC et [[LACNIC]] des Registres nationaux intermédiaires	+
−	(NIR) existent entre le RIR et les LIR présents dans ces pays.	+
−		+	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.
−	3) Les LIR attribuent des préfixes	+
−	IPv6 aux clients finaux. Ces préfixes ont typiquement des une	+
−	longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le	+
−	besoin du client et selon la politique du LIR en vigueur).	+
−		+
−	[[Image:Fig6-1.png|300px]]	+
−		+
−	Figure 6-1 ''Exemple de délégation de zones inverse''	+
−	La figure 6-1 montre qu’une liste de	+	Un serveur utilise le message REPLY (champ <tt>Type</tt> = 7) pour répondre à un message RENEW ou REBIND reçu d’un client.
−	serveurs DNS est associée à chaque nœud présent dans le sous-arbre	+
−	de nommage DNS inverse. Cette liste inclut généralement	+
−	un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés des	+
−	serveurs officiels pour cette zone DNS inverse.	+
−		+	Un client utilise le message RELEASE (champ <tt>Type</tt> = 8) pour indiquer au serveur DHCPv6 qu'il libère des adresses IPv6.
−	L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les	+
−	enregistrements PTR correspondant aux adresses IPv6 qu'il utilise) dans	+
−	ses zones DNS inverse.	+
−		+	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.
−	Par exemple, Renater a reçu le préfixe 2001:660::/32 et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa	+
−	de la part du RIPE-NCC. Renater a affecté le préfixe 2001:660:3006::/48 à l'AFNIC et lui a délégué la zone DNS inverse	+
−	correspondante :	+
		+	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é.
−	6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.	+	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.
−	6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.	+
−	6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.	+
−		+	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.
−	L'AFNIC publie alors dans sa zone	+
−	DNS inverse les enregistrements PTR	+
−	correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone	+
−	DNS :	+
−	$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.	+	=== Messages échangés entre relais et serveur===
−	1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.	+
−		+	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.
−	== Mises en œuvre du service DNS ==	+
−		+
−	=== Présentation du principe de configuration d’un serveur DNS ===	+
−		+
−	==== Configuration du fonctionnement du serveur ====	+
−		+	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.
−	==== Configuration de la zone ====	+
−		+	Un serveur DHCPv6 utilise le message RELAY-REPLY (champ <tt>Type</tt> = 13) pour envoyer un message à un client, via un relais.
−	==== Configuration des zones inverses ====	+
−		+	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.
−	=== Logiciels DNS supportant IPv6 ===	+
−		+
−	Il existe aujourd'hui de nombreux logiciels DNS, mais cette section ne les	+
−	liste pas de manière exhaustive.	+
−	Pour avoir une idée plus claire du nombre et de la diversité de ces	+	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é.
−	logiciels, le lecteur peut se référer à [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software cet article sur Wikipedia].	+
−		+	=== Tableau récapitulatif des messages DHCPv6 ===
−	Dans leurs versions récentes, la plupart de ces logiciels DNS supportent complètement	+	Le tableau ci-dessous résume le nom, le type, l'émetteur et la fonction des messages DHCPv6 échangés entre client et serveur.
−	IPv6, c'est-à-dire à la fois au niveau de la base de données (enregistrements AAAA et PTR)	+
−	et aussi au niveau transport IPv6 des messages DNS.	+
−		+	{|
−	Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de	+	|+'''Message DHCPv6'''
−	données.	+	! 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.
		+	|}
−	Par ailleurs, certaines distributions logicielles comportent	+	=== Extension du protocole DHCPv6 [RFC 6422] ===
−	l'implémentation du client et du serveur, d'autres n'incluent que l'implémentation	+	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.
−	du client ou que celle du serveur.	+
−		+
−	Par exemple, la distribution http://www.isc.org/downloads/bind/ BIND 9] développée par	+
−	l'ISC (''Internet Systems Consortium'') représente la référence de fait	+
−	dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et	+
−	outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...).	+
−		+	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.
−	Les distributions BIND 9 ont l'avantage d'être disponibles en code source et	+
−	en format binaire pour la quasi-totalité des plates-formes (Unix, MS	+
−	Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les	+
−	exemples de fichiers de configuration.	+
−		+	== Structure des messages DHCPv6 ==
−	Notons que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et qu'ils	+
−	présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir,	+
−	récursif ou officiel uniquement. Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le serveur	+
−	récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS officiel	+
−	(sans récursion) et [http://unbound.net/ Unbound] comme serveur	+
−	récursif pour l'une et/ou l'autre deux raisons : leurs performances et leurs	+
−	diversité génétique.	+
−	* '''Performances'''. leurs performances sont reconnues (des tests de performances comparant, d'un côté, NSD et BIND, et de l'autre , Unbound et BIND montrent la supériorité respective des premiers sur les seconds) ;	+
−	* '''Diversité génétique.''' La diversité générique concerne la diversité des plates-formes	+
−	logicielles supportant ces serveurs.	+
−		+	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.
−	=== Clients et outils de vérification de configurations DNS ===	+
−		+
−	Un client DNS, résolveur, se	+
−	présente souvent sous forme d'une bibliothèque de nommage. Cette dernière se	+
−	nomme « libresolv ». Ce client est appelé « resolver » ou encore « stub resolver ».	+
−		+	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.
−	Rappelons que ce resolveur est sollicité par les applications	+
−	TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les	+
−	ressources DNS nécessaires à l'établissement de leur communication avec des	+
−	applications distantes.	+
−		+	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>.
−	Outre le resolveur, Des outils et commandes dépendant	+	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.
−	des systèmes d'exploitation existent. Ils permettent d'interroger un serveur	+
−	DNS dans un but de mettre au point et/ou dépanner. Par exemple, les outils dig, host et nslookup font partie des	+
−	distributions BIND. Nous présentons des exemples de leur utilisation dans la	+
−	suite de cette partie.	+
−		+	=== Structure des messages émis par les serveurs et clients DHCPv6 ===
−	Notez que lorsque le serveur interrogé n'est pas explicitement renseigné	+	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).
−	lors de l’invocation de ces commandes, les serveurs par défaut sont interrogés.	+
−		+	<center>
−	Il peut, par exemple, s’s'agir de la liste des serveurs récursifs configurée	+	[[Image:MOOC_dhcp_Fig1.png|400px|center|thumb|Figure 5 : Format des messages échangés entre clients et serveurs DHCPv6.]]
−	automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de	+	</center>
−	configuration (/etc/resolv.conf pour les systèmes Unix) ou via une	+
−	interface graphique de l’équipement (MS Windows et Mac OS).	+
−		+	<tt>Type-msg</tt> : le champ <tt>type de message</tt> identifie la nature du message DHCPv6. Il est codé sur un octet.
−	Les mécanismes de découverte de la liste des serveurs DNS récursifs sont	+
−	décrits plus loin dans la section découverte de la liste de serveurs DNS	+
−	récursifs, Voir Découverte de la liste de serveurs DNS récursifs.	+
−		+	<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.
−	L'exemple suivant décrit le fichier <tt>resolv.conf</tt> d’un système Unix :	+
−	search nic.fr # domaine de recherche par défaut	+	<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.
−	nameserver ::1 # prefer localhost-v6	+
−	nameserver 192.134.4.162 # backup v4	+
−		+
−	==== Exemples d'interrogation  d’un serveur DNS avec dig ====	+
−		+
−	Les six exemples suivants illustrent l'utilisation des outils résolveur dig, host et nslookup pour obtenir l’adresse	+
−	IPv6 de la machine `ns3.nic.fr'.	+
−		+	Pour en savoir plus sur les options, reportez-vous à l’annexe 1 ''Options du protocole DHCPv6'' de cette activité.
−	$ '''dig ns3.nic.fr aaaa'''	+
−	; &lt;&lt;&gt;&gt; DiG 9.3.3 &lt;&lt;&gt;&gt; ns3.nic.fr aaaa	+
−	;; global options: printcmd	+
−		+
−	;; Got answer:	+
−	;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 3032	+
−	;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7	+
−		+
−	;; QUESTION SECTION:	+
−	;ns3.nic.fr. IN AAAA	+
−		+
−	;; ANSWER SECTION:	+
−	ns3.nic.fr. 172800 IN AAAA 2001:db8:3006:1::1:1	+
−		+
−	;; AUTHORITY SECTION:	+
−	nic.fr. 78032 IN NS ns1.nic.fr.	+
−	nic.fr. 78032 IN NS ns2.nic.fr.	+
−	nic.fr. 78032 IN NS ns3.nic.fr.	+
−	nic.fr. 78032 IN NS ns-sec.ripe.net.	+
−	[...]	+
−		+
−	;; ADDITIONAL SECTION:	+
−	ns1.nic.fr. 78032 IN A 192.93.0.1	+
−	ns1.nic.fr. 17168 IN AAAA 2001:db8:3005:1::1:1	+
−	ns2.nic.fr. 25737 IN A 192.93.0.4	+
−	ns2.nic.fr. 25737 IN AAAA 2001:db8:3005:1::1:2	+
−	ns-sec.ripe.net. 96368 IN A 193.0.0.196	+
−	ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4	+
−		+
−	;; Query time: 2 msec	+
−	;; SERVER: ::1#53(::1)	+
−	;; WHEN: Thu Oct 25 19:13:54 2007	+
−	;; MSG SIZE rcvd: 350	+
−		+
−	$ '''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''	+
−	</pre>	+
−		+
−	<pre>; &lt;&lt;&gt;&gt; DiG 9.3.3 &lt;&lt;&gt;&gt; ns3.nic.fr aaaa @ns-sec.ripe.net	+
−	</pre>	+
−	<pre>;; global options: printcmd	+	=== Structure des messages échangés entre relais et serveur DHCPv6 ===
−	</pre>	+	La figure 6 présente la structure des messages échangés entre relais et serveur.
−	<pre>;; Got answer:	+	<center>
−	</pre>	+	[[Image:MOOC_dhcp_Fig2.png|400px|center|thumb|Figure 6 : Format des messages échangés entre relais et serveurs DHVPv6.]]
		+	</center>
−	<pre>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 16927	+	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.
−	</pre>	+
−	<pre>;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5	+	<tt>Type-msg</tt> : le type du message identifie le type du message DHCPv6.
−	</pre>	+
−		+
−	<pre>;; QUESTION SECTION:	+
−	</pre>	+
−	<pre>;ns3.nic.fr. IN AAAA	+	<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.
−	</pre>	+
−		+
−	<pre>;; ANSWER SECTION:	+
−	</pre>	+
−	<pre>ns3.nic.fr. 345600 IN AAAA 2001:db8:3006:1::1:1	+	<!--
−	</pre>	+	<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).
−		+
−	<pre>;; AUTHORITY SECTION:	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)	+
−	</pre>	+
−		+
−	<pre>&gt;host -t aaaa ns3.nic.fr	+
−	</pre>	+
−	<pre>ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1	+	<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.
−	</pre>	+	-->
−		+	<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.
−	<pre>&gt;host -t aaaa ns3.nic.fr ns-sec.ripe.net	+
−	</pre>	+
−	<pre>Using domain server:	+	<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.
−	</pre>	+
−	<pre>Name: ns-sec.ripe.net	+	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.
−	</pre>	+
−	<pre>Address: 2001:610:240:0:53::4#53	+	==== Message DHCPv6 RELAY-FORWARD ====
−	</pre>	+
−	<pre>Aliases:	+	<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 12.
−	</pre>	+
−		+
−	<pre>ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1	+
−	</pre>	+
−		+
−	<pre>&gt;nslookup -type=aaaa ns3.nic.fr	+
−	</pre>	+
−	<pre>Server: 2001:db8:3003:2::1:1	+	<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais traversés par ce message pour atteindre le serveur.
−	</pre>	+	<!--
		+	<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.
−	<pre>Address: 2001:db8:3003:2::1:1#53	+	<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.
−	</pre>	+	-->
−		+
−	<pre>Non-authoritative answer:	+
−	</pre>	+
−	<pre>ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1	+	<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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>&gt;nslookup -type=aaaa ns3.nic.fr -secripe.net	+
−	</pre>	+
−	<pre>Server: ns-sec.ripe.net	+	<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.
−	</pre>	+
−	<pre>Address: 2001:610:240:0:53::4#53	+	<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.
−	</pre>	+
−		+
−	<pre>ns3.nic.fr has AAAA address 2001:db8:3006:1::1:1	+
−	</pre>	+
−		+
−	Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par	+
−	défaut (2001:db8:3003:2::1:1).	+
−	Dans les exemples 2, 4 et 6, la requête est envoyée au serveur ns-sec.ripe.net (qui est secondaire pour	+
−	la zone nic.fr).	+
−		+	Notez qu'en aucun cas le relais ne modifie le message DHCPv6 du client.
−	Notons que l'outil nslookup	+
−	n'est plus maintenu par l'[[ISC]]. Il est donc amené à disparaître.	+
−		+	==== Message DHCPv6 RELAY-REPLY ====
−	L'usage des outils dig	+
−	ou host pour toutes sortes de	+
−	requêtes est, en revanche, recommandé.	+
−		+	Le serveur envoie ce message au premier relais sur le chemin du retour vers le client demandeur.
−	L'AFNIC utilise la deuxième version de l’ooutil ZoneCheck pour	+
−	vérifier et valider la configurationde la délégation	+
−	de zones DNS des domaines .fr et .re.	+
−	Cet outil supporte complètement IPv6.	+
−		+	<tt>Type-msg</tt> : le champ <tt>type</tt> de ce message vaut 13.
−	[[ZoneCheck]] interroge la liste de ses serveurs officiels	+
−	d’une zone DNS pour vérifier leur bon fonctionnement et la bonne configuration	+
−	de la zone DNS en question.	+
−		+	<tt>Hop-count</tt> : le nombre de sauts indique le nombre de relais que ce message traversera pour atteindre le client.
−	Cet outil verifie le bon fonctionnement, en termes	+
−	de transports UDP et TCP, au-dessus d'IPv4 et d'IPv6, si IPv6 est supporté. Il	+
−	vérifie également la cohérence de la base de donnnées.	+
−	C'est-à-dire, celle des enregistrements DNS sur les différents serveurs	+
−	officiels.	+
−		+	<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.
−	Configuration de serveur/zone DNS	+
−		+	<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.
−	Même si les logiciels DNS utilisés interfonctionnent,	+
−	la syntaxe et les règles de configuration varient considérablement d'une	+
−	implémentation à l'autre.	+
−		+	=== Types de DUID : DHCPv6 Unique IDentifier ===
−	Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe	+
−	et les règles de BIND 9. Ce logiciel estconsidéré	+
−	aujourd'hui comme l'implémentation de référence.	+
		+	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'').
−	==== Fichier de configuration d'un serveur BIND9 ====	+	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.
−		+
−	La configuration d’un serveur BIND9 concerne quatre	+
−	aspects : la configuration du fonctionnement du serveur, la configuration	+
−	du statut du serveur, primaire ou	+
−	secondaire, la configuration du fichier de zone pour la résolution nom -	+
−	adresse et la configuration des fichiers de zone pour la résolution	+
−	inverse. Il y a un fichier de zone	+
−	par lien ou sous-réseau dans la zone.	+
−		+	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.
−	Pour tenir compte de cette modularité, le fichier principal	+	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.
−	de configuration de BIND9 se contente d’d’inclure d’autres fichiers gérant	+
−	spécifiquement un des aspects précédents.	+
−		+	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 :
−	Le fichier de configuration du	+	* <tt>1</tt> : '''''DUID-LLT''''' ''(Link-Layer address plus Time)'' résultant de la combinaison d'une adresse physique et d'une horodate ;
−	serveur de nom BIND 9 est, par exemple sous Linux, /etc/bind9/named.conf. Ce fichier se contente d’inclure	+	* <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 ;
−	d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations	+	* <tt>3</tt> : '''''DUID-LL''''' ''(Link-Layer address)'' dérivé de l'adresse MAC d'une interface de réseau.
−	relatives à un aspect de la configuration du serveur.	+
−		+	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.
−	Configuration du fonctionnement	+
−	du serveur. Le fichier option	+
−	contient, par exemple, différentes options de configuration du fonctionnement	+
−	du serveur, telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6,	+
−	l'activation ou non du mode récursif	+
−		+	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)''.
−	Configuration des zones. Le	+
−	fichier confient	+
−	les chemins d’accès aux zones pour lesquelles le serveur est officiel, il	+
−	définit également le chemin d'accès aux données (option directory) et le rôle	+
−	du serveur pour chacune des zones (primaire ou secondaire).	+
−		+	=== Association d'identités ===
−	Les zones DNS pour lesquelles le serveur (primaire ou secondaire) est	+
−	officiel sont ensuite déclarées successivement grâce à des rubriques de type	+
−	zone. Pour chaque zone. Le nom du fichier contenant les enregistrements de chaque	+
−	zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on	+
−	indique (à l'aide de la sous-rubrique slave ) la liste des adresses IPv4	+
−	et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici	+
−	maintenant un extrait du fichier named.conf du serveur DNS ns3.nic.fr :	+
−		+	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.
−	<pre>options {	+
−	</pre>	+
−	<pre> directory &quot;/usr/local/bind&quot;;	+	Un client associe au moins une association d’identités, IA, à chacune des interfaces de réseau pour laquelle il requiert une adresse IPv6.
−	</pre>	+
−	<pre> recursion no;	+	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.
−	</pre>	+
−	<pre> listen-on { any;};	+	Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées, T1 et T2, où :
−	</pre>	+	* 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.
−	<pre> listen-on-v6 {any; };	+	Un serveur DHCPv6 peut allouer deux types d'adresses IPv6 :
−	</pre>	+	* des adresses non temporaires ;
		+	* des adresses temporaires.
−	<pre> [...]	+	==== Allocation des adresses non temporaires ====
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>zone &quot;.&quot; {	+
−	</pre>	+
−	<pre> type hint;	+	Les adresses allouées font l'objet d'une écriture dans le fichier des baux.
−	</pre>	+
−	<pre> file &quot;named.root&quot;;	+	==== Allocation des adresses temporaires ====
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>zone &quot;localhost&quot; {	+
−	</pre>	+
−	<pre> type master;	+	Le serveur DHCPv6, s'il est configuré pour cela, effectue des mises à jour dynamiques sécurisées du service de noms de domaines.
−	</pre>	+
−	<pre> file &quot;localhost&quot;;	+	=== Options du protocole DHCPv6===
−	</pre>	+
−	<pre>};	+	Chaque option est codée en format TLV : type, longueur, valeur ; à savoir :
−	</pre>	+	* 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 ;
−	<pre>// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4	+	* le champ <tt>valeur du paramètre de configuration</tt>.
−	</pre>	+
−		+
−	<pre>zone &quot;0.0.127.in-addr.arpa&quot; {	+
−	</pre>	+
−	<pre> type master;	+	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.
−	</pre>	+
−	<pre> file &quot;localhost.rev&quot;;	+	Le tableau qui suit présente les options du protocole DHCPv6, leur code et leur définition. L’annexe 1 présente leur structure.
−	</pre>	+
−	<pre>};	+	{|
−	</pre>	+	|+'''Options de DHCPv6'''
−		+	! Désignation || Code || Définition
−	<pre>// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour	+	|-style="background:silver"
−	</pre>	+	|<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''.
		+	|}
−	<pre>// l'adresse loopback en IPv6	+	== Délégation de préfixe  à états ==
−	</pre>	+	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.
−		+
−	<pre>zone &quot;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa&quot; {	+
−	</pre>	+
−	<pre> type master;	+	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).
−	</pre>	+	Le routeur demandeur émet ses demandes sur l'interface qui donne accès au routeur délégataire.
−	<pre> file &quot;localhost.rev&quot;;	+	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é.
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>zone &quot;nic.fr&quot; {	+
−	</pre>	+
−	<pre> type slave;	+	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.
−	</pre>	+
−	<pre> file &quot;zone/nic.fr&quot;;	+	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.
−	</pre>	+	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).
−	<pre> masters {	+	Notez que la délégation de préfixe à états est indépendante de l'allocation des adresses IPv6.
−	</pre>	+
−	<pre> 2001:db8:3005:1::1:1; 192.93.0.1;	+	=== Applications de la délégation de préfixe ===
−	</pre>	+
−	<pre> 2001:db8:3005:1::1:2; 192.93.0.4;	+	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.
−	</pre>	+
−	<pre> };	+	<center>
−	</pre>	+	[[Image:MOOC_dhcp_Fig10.png|400px|center|thumb|Figure 7 : Exemple de délégation de préfixe à états.]]
		+	</center>
−	<pre>};	+	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.
−	</pre>	+	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.
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24	+
−	</pre>	+
−		+
−	<pre>zone &quot;0.134.192.in-addr.arpa&quot; {	+
−	</pre>	+
−	<pre> type slave;	+	==== Renumérotation des réseaux ====
−	</pre>	+	La renumérotation peut se faire de deux façons : passive ou active.
−	<pre> file &quot;rev/nic.fr.192.134.0&quot;;	+	===== Renumérotation passive =====
−	</pre>	+	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.
−	<pre> masters {	+	===== Renumérotation active =====
−	</pre>	+	Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une ancienne adresse et d'une nouvelle.
−	<pre> 2001:db8:3005:1::1:1; 192.93.0.1;	+	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.
−	</pre>	+
−	<pre> 2001:db8:3005:1::1:2; 192.93.0.4;	+	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.
−	</pre>	+
−	<pre> };	+	Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les machines autoconfigurent leurs nouvelles adresses.
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>// Blocs Ripe sous ip6.arpa.	+
−	</pre>	+
−		+
−	<pre>zone &quot;6.0.1.0.0.2.ip6.arpa&quot; {	+
−	</pre>	+
−	<pre> type slave;	+	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.
−	</pre>	+
−	<pre> file &quot;rev/6.0.1.0.0.2.ip6.arpa&quot;;	+	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.
−	</pre>	+	''(l'annexe 4 présente la structure de l'option d'association d'identités pour la délégation de préfixes).''
−	<pre> masters {	+	=== Principe de l'allocation ===
−	</pre>	+
−	<pre> 2001:610:240:0:53::3;	+	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.
−	</pre>	+	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).
−	<pre> 193.0.0.195;	+	<center>
−	</pre>	+	[[Image:MOOC_dhcp_Fig13.png|400px|center|thumb|Figure 8 : Allocation de préfixe par un routeur délégataire.]]
		+	</center>
−	<pre> };	+	=== Principe de l'allocation de préfixe à états avec relais ===
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:db8:3006::/48	+
−	</pre>	+
−		+
−	<pre>zone &quot;6.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa&quot; {	+
−	</pre>	+
−	<pre> type slave;	+	Le serveur renvoie son message RELAY-REPLY au relais.
−	</pre>	+
−	<pre> file &quot;rev/6.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa&quot;;	+	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).
−	</pre>	+
−	<pre> masters {	+	<center>
−	</pre>	+	[[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>
−	<pre> 2001:db8:3005:1::1:1; 192.93.0.1;	+	== Conclusion ==
−	</pre>	+	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.
−	<pre> 2001:db8:3005:1::1:2; 192.93.0.4;	+	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).
−	</pre>	+
−	<pre> };	+	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.
−	</pre>	+
−	<pre>};	+	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.
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	L'option « listen-on » peut avoir comme valeurs	+
−	possibles :	+
−		+	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.
−	* any : dans ce      cas-là, le serveur écoutera sur toutes ces adresses IPv4      opérationnelles ;	+
−	* une liste explicite comprenant une ou plusieurs      adresses IPv4 données : le serveur écoutera uniquement sur ses      adresses pour ce qui est du transport IPv4 des requêtes et réponses ;	+
−	* none : pas de support d'IPv4 (cette valeur n'est      pas utilisée aujourd'hui).	+
−		+
−	Par défaut, le serveur de nom BIND 9 ne va pas écouter les requêtes qui	+
−	arrivent sur une interface IPv6. Pour changer ce comportement par défaut, on va	+
−	utiliser l'option listen-on-v6	+
−		+	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.
−	L'option « listen-on-v6 »	+	<!--
−	peut avoir comme valeurs possibles :	+	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 ==
−	* any : dans ce      cas-là, le serveur écoutera sur toutes ses adresses IPv6      opérationnelles ;	+	<references />
−	* une liste explicite comprenant une ou plusieurs      adresses IPv6 données : le serveur écoutera uniquement sur ces      adresses pour ce qui est du transport IPv6 des requêtes et réponses ;	+
−	* none : pas de support d'IPv6 (valeur par      défaut).	+
−		+
−	Les cinq premières zones déclarées font partie de la configuration d'un	+
−	serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple	+
−	parmi les nombreuses zones sur lesquelles le serveur ns3.nic.fr fait autorité.	+
−		+	== Pour aller plus loin==
−	==== Fichier de zone DNS pour la résolution nom-adresse (DNS direct) ====	+	RFC et leur analyse par S. Bortzmeyer :
−		+	<!--
−	Voici à titre d'exemple, un extrait du fichier de zone DNS direct `nic.fr', faisant apparaître en même temps	+	* RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]
−	des adresses IPv4 et IPv6.	+	* RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [http://www.bortzmeyer.org/3633.html Analyse]
−		+	-->
−		+	* RFC 5007 DHCPv6 Leasequery
−	Remarquez dans cet exemple que les adresses IPv6 ont été construites	+	* RFC 6422 Relay-Supplied DHCP Options
−	manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans	+	* RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
−	ce contexte que les adresses obtenues par auto-configuration dérivent	+	<!--* RFC 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options -->
−	généralement de l'adresse physique de la carte réseau utilisée ([[RFC 4291]]).	+	* RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
−		+
−		+
−	<pre>$TTL 172800	+
−	</pre>	+
−		+
−	<pre>$ORIGIN nic.fr.	+
−	</pre>	+
−		+
−	<pre>@ IN SOA maya.nic.fr. hostmaster.nic.fr. (	+
−	</pre>	+
−		+
−	<pre> 2007102200 ;serial	+
−	</pre>	+
−		+
−	<pre> 21600 ;refresh (6 h)	+
−	</pre>	+
−		+
−	<pre> 3600 ;retry (1 h)	+
−	</pre>	+
−		+
−	<pre> 3600000 ;expire	+
−	</pre>	+
−		+
−	<pre> 86400 ) ;minimum (2 j)	+
−	</pre>	+
−		+
−	<pre> IN NS ns1.nic.fr.	+
−	</pre>	+
−		+
−	<pre> IN NS ns2.nic.fr.	+
−	</pre>	+
−		+
−	<pre> IN NS ns3.nic.fr.	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre> IN MX 10 mx1.nic.fr.	+
−	</pre>	+
−		+
−	<pre> IN MX 20 mx2.nic.fr.	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre> ns1 IN A 192.93.0.1	+
−	</pre>	+
−		+
−	<pre> IN AAAA 2001:db8:3005:1::1:1	+
−	</pre>	+
−		+
−	<pre> ns2 IN A 192.93.0.4	+
−	</pre>	+
−		+
−	<pre> IN AAAA 2001:db8:3005:1::1:2	+
−	</pre>	+
−		+
−	<pre> ns3 IN A 192.134.0.49	+
−	</pre>	+
−		+
−	<pre> IN AAAA 2001:db8:3006:1::1:1	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre> www IN CNAME rigolo	+
−	</pre>	+
−		+
−	<pre> rigolo IN A 192.134.4.20	+
−	</pre>	+
−		+
−	<pre> IN AAAA 2001:db8:3003:2::4:20	+
−	</pre>	+
−		+
−	<pre> kerkenna IN A 192.134.4.98	+
−	</pre>	+
−		+
−	<pre> IN AAAA 2001:db8:3003:8::4:98	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	==== Fichier de zone DNS inverse en IPv6 ====	+
−		+
−	Voici un extrait de fichier de zone DNS inverse correspondant au préfixe	+
−	IPv6 2001:db8:3003::/48	+
−	(réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements	+
−	de type PTR d'équipements supportant IPv6 :	+
−		+
−		+
−	<pre>$ORIGIN 3.0.0.3.0.8.B.d.1.0.0.2.ip6.arpa.	+
−	</pre>	+
−		+
−	<pre>$TTL 172800	+
−	</pre>	+
−		+
−	<pre>@ IN SOA maya.nic.fr. hostmaster.nic.fr. (	+
−	</pre>	+
−		+
−	<pre> 2007031200 ;serial	+
−	</pre>	+
−		+
−	<pre> 43200 ;refresh (12 h)	+
−	</pre>	+
−		+
−	<pre> 14400 ;retry (4 h)	+
−	</pre>	+
−		+
−	<pre> 3600000 ;expire	+
−	</pre>	+
−		+
−	<pre> 3600 );	+
−	</pre>	+
−		+
−	<pre> IN NS ns1.nic.fr.	+
−	</pre>	+
−		+
−	<pre> IN NS ns2.nic.fr.	+
−	</pre>	+
−		+
−	<pre> IN NS ns3.nic.fr.	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	<pre>0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.	+
−	</pre>	+
−		+
−	<pre>7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.	+
−	</pre>	+
−		+
−	<pre>1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.	+
−	</pre>	+
−		+
−	<pre>8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.	+
−	</pre>	+
−		+
−	<pre>[...]	+
−	</pre>	+
−		+
−	== 1.4.            Recommandations opérationnelles pour l'intégration d'IPv6 ==	+
−		+
−	Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la	+
−	particularité d'être à la fois une application TCP/IP et une infrastructure	+
−	critique.	+
−		+
−		+
−	Le DNS est une application critique prcequ’elle	+
−	permet à toutes les autres autres applications TCP/IP	+
−	classiques (web, mail, ftp, ...) de fonctionner.	+
−		+
−		+
−	Le DNS est une infrastructure critique car c’est la base de données	+
−	distribuée la plus grande échelle qui soit.	+
−		+
−		+
−	L'intégration progressive d'IPv6, entraîne de nouveaux problèmes	+
−	opérationnels liés au DNS : la fragmentation de l’espace de nommage,	+
−		+
−		+
−	Il convient donc, soit de les éviter, soit de trouver les	+
−	solutions adéquate pour y remédier.	+
−		+
−		+
−	À cet effet les [[RFC 3901]] et [[RFC 4472]] identifient les	+
−	principaux problèmes et formulent une série de recommandations pratiques pour y	+
−	faire face. Les sections qui suivent tentent de résumer ces recommandations	+
−		+
−		+
−	=== 1.4.1.              Les deux aspects du DNS ===	+
−		+
−	Le DNS supporte les enregistrements A et AAAA	+
−	et ce, indépendamment de la version d'IP qui est utilisée pour transporter les	+
−	requêtes et réponses DNS relatives à ces enregistrements.	+
−		+
−		+
−	Par ailleurs, en tant qu'application TCP/IP, un serveur DNS utilise les	+
−	transports UDP IPv4 ou IPv6 ou les deux à la fois.	+
−		+
−		+
−	Dans tous les cas, le serveur DNS doit satisfaire une requête donnée en	+
−	revoyant les informations qu'il a dans sa base de données, indépendamment de la	+
−	version d'IP sur laquelle il a reçu cette requête.	+
−		+
−		+
−	Un serveur DNS ne peut pas, a priori, savoir si le résolveur initiateur de	+
−	la requête l’a transmis à son serveur récursif (cache) en utilisant IPv4	+
−	ou en IPv6.	+
−		+
−		+
−	En effet des serveurs intermédiaires (cache forwarders)	+
−	peuvent intervenir dans la chaîne des serveurs interrogés durant le processus	+
−	de résolution d’une requête DNS. Ces serveurs intermédiaires (cache forwarders) n'utilisent pas nécessairement la même version d'IP que leurs clients.	+
−		+
−		+
−	En outre, en supposant que le serveur DNS puisse connaître la version d'IP	+
−	utilisée par le client qui a initié la requête, notez qu’il n'a pas à faire	+
−	d'hypothèse sur l'usage de la réponse DNS renvoyée par le client.	+
−		+
−		+
−	=== 1.4.2.              Impossibilités d’accès au service DNS et remèdes ===	+
−		+
−	Cette partie présente deux scénarios où l’accès au DNS est	+
−	impossible et les remèdes qui permettent d’éviter cette situation.	+
−		+
−		+
−	Avant IPv6, le processus de résolution DNS ne faisait intervenir qu’IPv4. Le	+
−	service était donc garanti pour tous les clients DNS.	+
−		+
−		+
−	Avec IPv6, on risque de se trouver confronté à des cas où l'espace de	+
−	nommage est fragmenté où certains fragments de cet espace ne sont accessibles que	+
−	via IPv4, et d'autres ne sont accessibles que via IPv6.	+
−		+
−		+
−	Voici par exemple deux scénarios illustrant ce problème de fragmentation de	+
−	l’espace d’adressage ainsi que la solution recommandée dans chaque	+
−	scénario :	+
−		+
−		+
−	==== Premier scénario : client IPv4 et serveur IPv6 ====	+
−		+
−	Un client ne supportant qu'IPv4 envoie une requête relative	+
−	à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ce cas, le	+
−	processus de résolution échoue du fait de l'impossibilité d'accéder aux	+
−	serveurs officiels de cette zone.	+
−		+
−		+
−	Faire en sorte que toute zone DNS soit servie par au moins	+
−	un serveur officiel supportant IPv4 remédie à ce problème.	+
−		+
−		+
−	==== Second scénario : client IPv6 et serveur IPv4 ====	+
−		+
−	Un client ne supportant qu'IPv6 envoie une requête relative	+
−	à une zone DNS hébergée sur des serveurs ne supportant qu'IPv4. Si le serveur	+
−	récursif interrogé ne supporte pas non plus IPv4, le processus de résolution	+
−	risque d'échouer du fait de l’impossibilité pour ce serveur récursif de joindre	+
−	les serveurs officiels de la zone concernée supportant IPv6.	+
−		+
−		+
−	Configurer le serveur récursif en le faisant pointer vers un	+
−	serveur forwarder en double pile IPv4/IPv6 remédie à ce	+
−	problème.	+
−		+
−		+
−	Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :	+
−		+
−		+
−	<pre>forwarders {&lt;liste des adresses de serveurs forwarders&gt; ;}	+
−	</pre>	+
−		+
−	sous la rubrique « options » dans le fichier named.conf.	+
−		+
−		+
−	=== 1.4.3.              Taille limitée des messages DNS en UDP ===	+
−		+
−	Les implémentations DNS s'appuient essentiellement sur deux standards de	+
−	l'IETF ([[RFC 1034]] et [[RFC 1035]]). De nombreux autres	+
−	RFC complémentaires ont été publiés plus tard pour clarifier certains aspects	+
−	pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux	+
−	besoins (enregistrements AAAA, SRV, extensions DNSSEC, ...). Le DNS, en	+
−	tant qu'application TCP/IP, doit supporter les deux modes de transport UDP et	+
−	TCP ([[RFC 1035]]), le port associé à	+
−	l’application DNS est le même pour	+
−	TCP et UDP : 53.	+
−		+
−		+
−	Le protocole de transport UDP	+
−	est généralement utilisé pour acheminer les requêtes/réponses DNS. Le protocole	+
−	de transport TCP est généralement	+
−	utilisé pour les transferts de zones entre serveur primaire et secondaires.	+
−		+
−		+
−	Lorsque le DNS utilise le protocole de transport UDP, la taille des messages	+
−	DNS est limitée à 512 octets. Certaines requêtes, trop grandes pour être	+
−	acheminées par UDP provoquent le	+
−	sont par TCP.	+
−		+
−		+
−	Dans ce cas, le client reçoit, dans un premier temps, un message dont la	+
−	section réponse (''answer'''' section'') est	+
−	vide et dont le bit TC (''Truncated'') est positionné. Ceci signifie	+
−	implicitement que le client est invité à réinterroger le serveur en utilisant	+
−	TCP.	+
−		+
−		+
−	Notez que ce scénario constitue une justification du fait que le port 53 en TCP ne doit pas être	+
−	ouvert exclusivement pour des transferts de zones et qu'un recours trop	+
−	fréquent à TCP risque de consommer davantage de ressources, et par conséquent,	+
−	de dégrader les performances du serveur DNS.	+
−		+
−		+
−	Certains nouveaux types d'enregistrements (AAAA)	+
−	risquent d'augmenter significativement la taille des réponses DNS. ceci risque donc d’accoître le	+
−	nombre de recours à TCP pour satisfaire les requêtes/réponses DNS.	+
−		+
−		+
−	Aujourd'hui, ces dépassemens sont rares. La	+
−	plupart des réponses DNS ont une taille qui ne dépasse guère 400 octets. En	+
−	effet, les sections answer,	+
−	authority	+
−	et additional,	+
−	qui constituent l’essentiel de la réponse DNS, ne contiennent qu'un nombre	+
−	limité d'enregistrements lorsque cette réponse ne concerne pas directement une	+
−	zone racine telle que .com, .net, .fr, .de...	+
−		+
−		+
−	Face à ce risque, l’IETF a proposé l'extension EDNS.0 du protocole DNS (RFC 6891. Cette extension est déjà déployée	+
−	dans les versions récentes des logiciels DNS. Elle permet qu’	+
−	un client DNS informe le serveur interrogé qu’il supporte des réponses	+
−	de taille supérieure à la limite des 512 octets (par exemple, 4096 octets).	+
−	Ainsi, en présence d'IPv6, le support de l’extension du DNS, 'EDNS.0, devient	+
−	fortement recommandé.	+
−		+
−		+
−	Notez également que le support d'EDNS.0 devient aussi indispensable	+
−	en présence des extensions de sécurité de DNS, DNSSEC.	+
−		+
−		+
−	Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS, surtout les	+
−	clients est resté pendant plusieurs années un des principaux motifs du refus de	+
−	l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs	+
−	racine.	+
−		+
−		+
−	Depuis le 4 février 2008, l'[[IANA]] publie l'adresse IPv6 (enregistrement	+
−	AAAA) des serveurs racine supportant le transport IPv6 dans la zone racine. La	+
−	nouvelle version du fichier de de démarrage named.root de BIND 9) contient	+
−	également ces adresses.	+
−		+
−		+
−	Notez enfin que des informations sur les adresses IPv4 et IPv6 des serveurs	+
−	de la racine ainsi que sur la répartition géographique de ces serveurs sont	+
−	publiées sur le site web : [[http://www.root-servers.org/]].	+
−		+
−		+
−	=== 1.4.4.              Glue IPv6 ===	+
−		+
−	La zone racine publie également les adresses des différents serveurs DNS de	+
−	chacun des domaines racines (TLD : ''Top Level	+
−	Domain''). Ces adresses, appelées « glues » sont nécessaires au	+
−	démarrage du processus de résolution.	+
−		+
−		+
−	En effet, rappelons que les	+
−	serveurs DNS de la racine ne sont pas censés répondre eux-mêmes aux requêtes	+
−	des clients. Leur rôle est de faire le premier aiguillage (''referal'')	+
−	vers des serveurs racine (TLD).	+
−		+
−		+
−	Les informations d'aiguillage incluent	+
−	la liste des serveur racine sous lequel se trouve la ressource. Elles incluent	+
−	également les adresses (glues) de ces serveurs. Sans ces adresses, la	+
−	résolution ne peut se faire. Le client aurait le nom du serveur, mais pas son	+
−	adresse et ne pourrait l’obtenir…	+
−		+
−		+
−	En attendant que les serveurs racine puissent recevoir des requêtes DNS et	+
−	répondre en IPv6, les domaines racine TLD avaient pendant des années milité	+
−	pour l'introduction des « glues » IPv6 qui leurs sont associées dans	+
−	la zone racine.	+
−		+
−		+
−	L'IANA/ICANN a fini par être convaincue que la publication des adresses IPv6	+
−	des serveurs DNS racines supportant IPv6 pouvaitt se	+
−	faire sans risque pour la stabilité du DNS.	+
−		+
−		+
−	L'ICANN/IANA a démarré, en	+
−	juillet 2004, la publication des adresses IPv6 des domaines racines TLD dans la	+
−	zone racine. Les trois TLD .fr, .jp et .kr ont les premiers vu leur glue IPv6 publiée.	+
−		+
−		+
−	=== 1.4.5.              Publication des enregistrements AAAA dans le DNS ===	+
−		+
−	On choisit généralement de publier dans le DNS les enregistrements AAAA d’un équipement donné lorsque l'on	+
−	souhaite que les applications communiquant avec cet équipement découvrent le	+
−	support du transport IPv6.	+
−		+
−		+
−	Par exemple, un navigateur supportant IPv6, découvre ainsi grâce au DNS	+
−	qu'il est possible d’accéder en IPv6 au site http://www.afnic.fr/.	+
−	Il peut alors choisir de privilégier la connexion HTTP au serveur en IPv4 ou en	+
−	IPv6.	+
−		+
−		+
−	Or avec l'intégration	+
−	progressive d'IPv6 l'adresse IPv6 d’un équipement peut être publiée dans le DNS.	+
−	certaines	+
−	applications s'exécutant sur cet équipement peuvent ne pas supporter IPv6.	+
−		+
−		+
−	La situation suivante risque donc de se produire :	+
−		+
−		+
−	L'équipement foo.example.com	+
−	héberge plusieurs services : web, ftp, mail, DNS. Les serveurs Web et DNS	+
−	s'exécutant sur foo.example.com	+
−	supportent IPv6, mais pas les serveurs FTP et mail.Une	+
−	adresse IPv6 est publiée dans le DNS pour foo.example.com ;	+
−		+
−		+
−	Un client FTP supportant IPv6 tente d’accéder au serveur de	+
−	notre équipement : foo.example.com. Le client choisit	+
−	l'adresse IPv6 de foo.example.com comme adresse destination. La tentative d’accès	+
−	au serveur FTP en IPv6 échoue.	+
−	Selon les implémentations, les clients tentent ou non d’utiliser d'autres	+
−	adresses IPv6 s'il y en a ou finissent ou non par tenter d’y accéder, en	+
−	dernier recours, en IPv4.	+
−		+
−		+
−	Pour pallier à ce problème l’IETF recommande d'associer des noms DNS aux	+
−	services et non aux équipements.	+
−		+
−		+
−	Ainsi, pour notre exemple précédent, il serait judicieux de publier dans le DNS,	+
−	d'une part, les noms www.example.com	+
−	et ns.example.com associés à des	+
−	adresses IPv6, et éventuellement, des adresses IPv4, et d'autre part, les noms ftp.example.com et mail.example.com associés uniquement àdes adresses	+
−	IPv4.	+
−		+
−		+
−	L'enregistrement AAAA pour foo.example.com ne serait alors publié que lorsque l'on a la	+
−	certitude que toutes les applications s'exécutant sur cet équipement supportent	+
−	IPv6.	+
−		+
−		+
−	Par ailleurs, le DNS étant une ressource publique, il est fortement	+
−	déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il fait !)	+
−	d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une	+
−	portée faible (adresses locale au lien, par exemple), soit parce que toutes les	+
−	communications provenant de l'extérieur du réseau et allant vers ces adresses	+
−	sont filtrées.	+
−		+
−		+
−	Notez que cette règle est déjà appliquée pour les adresses IPv4 privées ([[RFC 1918]]) et que certains	+
−	logiciels DNS récents supportent aujourd'hui les vues DNS. On parle de ''two''''-face DNS'', de ''split-view	+
−	DNS'' ou encore de ''split DNS''.	+
−		+
−		+
−	Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du	+
−	client. Par exemple un client appartenant au réseau interne verra les adresses	+
−	privées des équipements alors que les clients externes ne verront eux que les	+
−	adresses globales et accessibles de l'extérieur.	+
−		+
−		+
−	=== Pour aller plus loin : Enregistrement et mise à jour du DNS par les clients ===	+
−		+
−	'''TODO''': Parler du DNS Dynamic Update pour les adresses IPv6 auto-configurées	+

---

Latest revision as of 09: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