Difference between revisions of "MOOC:Compagnon Act33-s7"

From Livre IPv6

(Identifiant DUID)
(Extension de l’autoconfiguration "sans état" pour le DNS)
 
(347 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__
= La configuration automatique centralisée par DHCPv6 =
+
= Activité 33 : Faire correspondre adresse et nom de domaine=
 +
<!-- {{Decouverte}} -->
 +
==Introduction==
  
== Introduction ==
 
  
L'autoconfiguration avec état utilise un serveur pour allouer des adresses ipv6 et/ou des paramètres decoonfiguration à des machines IPv6. Elle réduit les efforts de configuration des machines IPv6, tout comme l'autoconfiguration sans état d'ailleurs. 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.
+
Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS<ref>Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]</ref>.
  
Les deux techniques d'autoconfiguration, avec et sans états, ne sont pas exclusives et peuvent coexister dans un même environnement.
+
==Concepts de base du DNS==
  
Une machine peut, par exemple, obtenir son adresse unicast globale par autoconfiguration sans état et obtenir les informations relatives au service de noms (DNS) par l'autoconfiguration avec état.
+
Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines.
 +
Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP.  
  
Tout le mécanisme d'autoconfiguration avec état est bâti sur le modèle client-serveur. Il repose sur l'utilisation du protocole DHCPv6 (''Dynamic Host Configuration Protocol for IPv6'').
+
Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine.  Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.
  
== Principe ==
+
Une application qui s’exécute sur un équipement A, et qui souhaite 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 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. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées.
  
Le RFC 3315 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.
+
===Nommage « à plat »===
  
La mise au point de ce standard a cependant été l'objet de nombreux débats, DHCP étant un élément important du fonctionnement d'un réseau. En conséquence, la parution tardive d'un standard finalisé a entraîné une adoption lente, du support et du déploiement de ce mécanisme.
+
Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation.
 +
Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central.  
 +
Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier.
 +
Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.
  
=== Architecture du protocole ===
+
===Caractéristiques du système de noms de domaine===
Conformément au modèle client-serveur, les échanges DHCPv6 se composent de requêtes et de réponses. Ces échanges utilisent une pile de communication UDP/IPv6/réseau physique. Ils font intervenir quatre types d'entités : les client, les serveurs, les relais et les interrogateurs (requestor). Nous les présentons successivement.
+
  
== Principe de fonctionnement client-serveur ==
+
Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».
Un client DHCPv6 qui souhaite obtenir des adresses IPv6 et/ou des paramètres de configuration du réseau initie souvent une transaction en émettant une requête DHCPv6.
+
le client, pour éviter les avalanches de trafic, attends un temps aléatoire avant d'émettre sa première demande. Le client assure la fiabilité de la transaction en répétant sa requête DHCPv6 jusqu'à recevoir une réponse ou être sûr que le serveur DHCP est indisponible. Dans ce cas, il peut éventuellement décider de solliciter d'autres serveurs DHCPv6, s'il en  existe ou d'abandonner sa tentative de configuration.
+
  
Le serveur DHCPv6 répond au client en lui fournissant les adresses et/ou les paramètres de configuration du réseau demandés.
+
Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes "nom-adresse" et des correspondances inverses "adresse-nom". Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage 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 infrastructure critique pour 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.  
  
Lorsque le client et le serveur se trouvent sur le même mien, les interactions directes entre client et srveur sont possibles.
+
* <b>Hiérarchique.</b> Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). 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 à chacune de ses feuilles. 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 de l’arbre est un nœud qui n’a pas de fils.  Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom.  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 ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.
 +
{{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}
  
Lorsque le client et le serveur ne sont pas sur le même lien, un relais intervient. Le relais intercepte le message du client et l'encapsule dans un message de relais, plus précisémment dans une option de message relayé. Le message de relais est ensuite envoyé, soit au serveur DHCPv6, soit au relais suivant.  
+
<center>
 +
[[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]
 +
</center>
  
Si le message est transmis au serveur, le relais qui effectue l'envoi est le dernier sur le chemin qui relie le client au serveur.
+
Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).
 +
Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé "arpa" sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6.
 +
* <b>Réparti.</b> Nul 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 de 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.
 +
* <b>Robuste.</b> 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 géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois 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. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires.
 +
** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le 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.  
  
Si, au contraire le relais ne peut pas transmettre directement son message au serveur, il l'adresse à un autre relais. Le processus se poursuit jusquce qe le message atteigne le serveur DHCPv6.  
+
* <b>Extensible.</b> La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter 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.
 +
{{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}
 +
<center>
 +
[[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]
 +
</center>
  
Lorsque le serveur envoie sa réponse au client, la réponse issue du serveurest, soit envoyée directement au client, soit renvoyée au dernier relais. ce relais renvoie la réponse du client au relais précédent, et ainsi de suite jusqu'à ce que le dernier relais puisse remettre la réponse du serveur au client DHCPv6.
+
L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs.  
 +
Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des "sous-arbres". Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.
  
== Pile de communication utilisée par DHCPv6 ==
+
Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zoneSi, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3).
DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP.  
+
Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.
  
Un client DHCPv6 envoie les requêtes depuis le port 546 et les envoie vers le port 547 du serveur ou du premier relais.
+
<center>
 +
[[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la  hiérarchie de serveurs : avant après.]]
 +
</center>
  
Le serveur DHCPv6 envoie ses réponses depuis son port 547 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.
+
Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur.  Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.
  
Les messages UDP sont encapsulés dans des datagrammes IPv6.
+
===Principe de fonctionnement du service DNS===
  
En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6,  se faire en point à point ou en diffusion sélective (multicast) pour la découverte des serveurs DHCPv6 d'un site.
+
Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') 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). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''.  
  
IPv6 s'appuie ensuite sur les fonctions de diffusion, générale ou sélective, du réseau physique sous-jecent 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.
+
Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.
 +
<!--
 +
<center>
 +
[[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]
 +
</center>
 +
-->
 +
<center>
 +
[[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]
 +
</center>
  
== Présentation des entités du protocole DHCPV6  ==
+
Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.
  
Le protocole DHCPV6 pour fonctionner fait intervenir quatre entités : le client, le serveur, le relais et l'interrogateur. l'intervention de la quatrième entité, l'interrograteur est facultative.
+
<!--
 +
<center>
 +
[[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]
 +
</center>
 +
-->
 +
<!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. -->
  
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 doit maintenir une connectivité directe, soit avec un relais DHCPv6, soit avec le serveur DHCPv6 (c'est-à-dire être sur le même lien). Un client ignore l'existence des relais DHCPv6. Il a l'impression de communiquer directement avec le serveur DHCPv6.
+
On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. 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. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.
 +
<!--
 +
TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le
 +
-->
  
Le serveur DHCPv6  centralise les paramètres de configuration des équipements du réseau. Il peut ou non  se trouver  sur le même lien qu'un client DHCPv6. Il gère la configuration de clients situés sur le même lien ou sur des liens différents. Lorsqu'il ne se trouve pas sur le même lien que son client, les échanges DHCP transitent par un relais DHCPv6.  
+
Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.
  
Les relais DHCPv6 sont des équipements éventuellement 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. Leur action est transparente pour les clients.
+
=== Les serveurs de noms ===
  
Notez que ni les relais, ni le serveur ne modifieent les messages du client. Ils se contentent, en présence de relais, de les encapsuler dans une option de message de relais.  
+
L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.
  
Les interrogateurs (requestors) [RFC 5007] sont des entités spécifiques à destination des administrateurs. Ils interrogent un serveur DHCPV6 pour obtenir des informations relatives aux clients.
+
====Serveurs de noms primaires et secondaires====
  
Un administrateur peut, par exemple, interroger un serveur DHCPv6 pour obtenir des informations relatives aux baux d’un client ou à la machine qui utilise une adresse à un instant donné ou encore pour connaître les adresses allouées à un client donné. Nous ne détaillerons pas ici leur utilisation.
+
{{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}
 +
Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.
  
=== Gestion centralisée des ressources allouées ===
+
Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).
  
Dans la configuration DHCPv6 sans état (stateless), le client 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). Le client a pour se configurer besoin  d'informations telles que l'adresse IPv6 du serveur DNS. Ces informations transmises par DHCPv6 sont statiques. Elles ne nécessitent donc pas de conserver un état dans le serveur.
+
<center>
 +
[[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un  fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]
 +
</center>
  
Dans la configuration avec états (stateful), le serveur DHCPv6 alloue une ou plusieurs adresses IPv6 au client. Ces adresses font l’objet d’un contrat de location temporaire. Le serveur enregistre ce contrat de location dans un registre spécial : le fichier des baux (de location) (lease file). Pour cette raison, ce type de configuration est dit avec états.
+
<center>
 +
[[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]
 +
</center>
  
De plus, lorsqu'un serveur redémarre, il relit son fichier de baux. Il peut alors reprendre son activité là où il l'avait laissée.
+
{{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}
  
== Fonctions des Messages ==
+
Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation).  
Cette partie présente les messages du protocole DHCPv6. Le protocole distingue deux types de messages : d’une part les messages échangés entre client et serveur, et d’autre part les messages échanges entre serveur et relais. Nous les présentons successivement dans cet ordre. En général les messages échangés transportent des identificateurs de transaction et des associations d'identités.
+
  
Les identificateurs de transactions permettent d'associer les réponses aux demandes correspondantes. Ils changent pour chaque transaction et sont globalement uniques.
+
<b>Synchronisation par notification :</b> lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.
  
Les associations d'identités permettent aux serveur et aux clients de s'identifier mutuellement et également d'identifier les interfaces de réseau concernées par les paramètres de configuration du réseau demandés (client) ou fournis (serveur).  
+
<b>Synchronisation par interrogation :</b> lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.
  
Les associations d'identités sont également transmises dans des options du protocole DHCPv6.
 
  
=== Messages échangés entre client et serveur ===
+
<center>
 +
[[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]
 +
</center>
  
SOLICIT / ADVERTISE
 
Un client utilise le message SOLICIT (champ type 1) pour localiser les serveurs configurés pour allouer des adresses et/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).
+
Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).
  
=== Messages de demande d'information de configuration ===
+
<center>
 +
[[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]
 +
</center>
  
REQUEST / REPLY
+
Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.
  
Un client utilise le message REQUEST (champ type 3) pour demander des adresses et/ou des paramètres de configuration au serveur DHCPv6 choisi. Une option options demandées contient la liste des paramètres de configuration demandés.
+
====Serveur DNS récursif (''caching name server'')====
  
Un serveur utilise le message REPLY (champ type 7) pour répondre à un message SOLICIT, REQUEST, RENEW, REBIND reçu directement d’un client DCHPv6.
+
Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS "cache". Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.
  
=== Messages de gestion des ressources allouées ===
+
====Relais DNS (''forwarder'')====
  
CONFIRM / RENEW / REBIND / RELEASE / DECLINE / RECONFIGURE / INFORMATION REQUEST
+
Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit "relais DNS" (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.
  
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 que ces paramètres sont adaptés au lien auquel le client est raccordé.
+
Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de "l'autre coté" du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.
  
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.
+
====Serveurs DNS à rôles multiples====
  
Un client utilise le message REBIND (champ type 6) pour prolonger le 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 obtenir ses adresses et paramètres de configuration du réseau ne répond pas à son message RENEW.
+
Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients.  
  
Un serveur utilise le message REPLY (champ type 7) pour répondre à un message SOLICIT, REQUEST, RENEW ou  REBIND reçu d’un client.
+
Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.
  
Un client utilise le message RELEASE (champ type 8) pour indiquer au serveur DHCPv6 qu'il n’utilise plus (libère) des adresses IPv6.
+
===Spécifications du service de nommage===
 +
==== Spécifications du résolveur ====
 +
Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service 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.
 +
<!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. -->
 +
{{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}
 +
Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/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 serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé "Découverte de la liste des serveurs DNS récursifs".
 +
<!--
 +
Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces 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.
+
==== Spécifications des ressources IPv6 ====
 +
Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.
  
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.
+
Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.
 +
* Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.
 +
* Le nouveau sous-domaine ''<tt>ip6.arpa.</tt>'' est dédié à la résolution DNS inverse en IPv6 (correspondance "adresse IPv6" vers "nom"). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''
  
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.
+
===Nommage direct : enregistrement AAAA ===
  
=== Messages échangés entre relais et serveur  ===
+
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. <!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.-->
 +
''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR 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 multi-domiciliée ou routeur, par exemple))''.
  
RELAY-FORWARD / RELAY-REPLY
+
Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''.  
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).
+
Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant :
 
+
Un relais 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 destiné au client contenu dans l'option message relayé option de ce message RELAY-REPLY pour le lui remettre. Ici encore le message du client reste inchangé.
+
 
+
=== Pour en savoir plus : 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 3315] décrit l'ensemble des éléments du protocole DHCPv6. A 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 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ées 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.
+
 
+
Dans la terminologie DHCPv6, le terme message désigne une unité de 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.
+
 
+
0                  1                  2                  3 
+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|    Type-msg  |              Id-transaction                  |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
.                    Liste d’options                            .
+
.                          (variable)                          .
+
|                                                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
La structure générale des messages échangés entre client et serveur DHCPv6 est la  suivante : : un champ type, un champ identificateur de transaction, id-transaction, et une liste variable d’options.
+
 
+
 
+
Le champ type identifie la nature du message DHCPv6. Il est codé sur un octet.
+
 
+
L'identificateur de transaction identifie un échange (question-réponse). Il change pour chaque échange et est globalement unique. Il est codé sur 3 octets.
+
 
+
Les options de la liste transportent, soit les adresses IPv6, soit les paramètres de configuration du réseau (hors adresse IPv6).
+
 
+
La partie liste d'options est de taille variable. Elle correspond à une succession d'options rangées séquentiellement, les unes derrière les autres,  et uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options consécutives.
+
 
+
Les options de la liste transportent les différentes informations de configuration du réseau des messages de DHCPV6 ou nécessaires à son fonctionnement.
+
 
+
Pour en savoir plus sur les options, reportez-vous au chapitre sur les options.
+
 
+
 
+
=== Structure des messages échangés entre relais et serveur DHCPv6 ===
+
La structure des messages échangés entre relais et serveur est la suivante :
+
 
+
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
      |    Type-msg  |  hop-count  |                              |
+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
+
      |                                                              |
+
      |                        link-address                          |
+
      |                                                              |
+
      |                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
      |                              |                              |
+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
+
      |                                                              |
+
      |                        peer-address                          |
+
      |                                                              |
+
      |                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
      |                              |                              |
+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
+
      .                                                              .
+
      .            Options (variable number and length)  ....        .
+
      |                                                              |
+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
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 le serveur. Un message RELAY-REPLY transite du serveur vers le client.
+
 
+
Le type du message identifie le type du message DHCPv6. Le nombre de sauts (hop-count) 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. 
+
 
+
L'adresse locale au lien (link-address désigne l'interface du relais émettrice du message (RELAY-FORWARD) ou destinataire du message (RELAY-REPLY).
+
 
+
L'adresse du pair(<tt>peer-address</tt>) 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.
+
 
+
Ainsi, même en présence de plusieurs relais DHCPv6, le serveur sait auquel de ces 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 de relais contenu dans l'option de message de relais du message RELAY-REPLY reçu. 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.
+
 
+
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 et/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
+
| Prolonger le 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, Renew, Rebind reçu d’un client
+
|-
+
| RELEASE
+
| 8
+
| Client
+
| Indiquer au serveur que le client n’utilise plus des adressesipv6.
+
|-
+
| 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 au serveur des paramètres de configuration, sans demander d’adresse.
+
|-
+
| RELAY-FORW
+
| 12
+
| Relai
+
| Relayer des messages vers un serveur DHCPv6. Le message relayé (celui du client DHCPv6  est placé dans une option de ce message.
+
|-
+
| RELAY-REPL
+
| 13
+
| Serveur
+
| Envoyer un message à un relais, depuis un serveur. Le relais extrait le message destiné au client contenu dans ce message  pour le lui remettre.
+
|}
+
 
+
 
+
 
+
==== Message DHCPv6 RELAY-FORWARD====
+
Le champ type de ce message vaut 12. Le nombre de saut indique le nombre de relais traversés par ce message pour atteindre le serveur. L’adresse de lien (<tt>link-address</tt>) 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 (adresse du relais côté client). C'est l'adresse du relais, du côté du client.
+
L’adresse du pair <tt>Peer-address</tt> 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. La liste d’option 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. Le champ type de ce message vaut 13. Le nombre de saut indique le nombre de relais que ce message traversera pour atteindre le client. Les adresses du lien et du pair sont recopiées du message RELAY-FORWARD précédent.
+
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 valeurs ===
+
 
+
Le RFC 3315 définit 2 types de valeurs qui peuvent être transportée dans ces messages. [ je ne comprends pas ce titre B. Joachim  je propose de supprimer cette partie.]
+
 
+
==== Identifiant DUID ====
+
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 dépendant du serveur, celle-ci n'est pas utilisable par le serveur DHCP pour identifier un client. Le serveur identifie 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 son identifiant, même en cas de remplacement ultérieur de cette carte réseau.
+
 
+
Les clients utilisent les DUID pour identifier les serveurs quand et là où ils en ont besoin, par exemple, pour mémoriser l'identité du serveur qui leur a alloué des adresses IPv6 et/ou des paramètres de configurationdu réseau.
+
 
+
Le contenu des DUID n’est pas interprété, mais uniquement utilisé pour des comparaisons pour vérifier l'identité du correspondant. Le DUID concerne la machine (client ou serveur) et non une de ces interfaces.
+
 
+
Les DUID sont codés sur deux octets et ont une longueur inférieure à 128 octets (hors champ type). Ils peuvent être généré selon 3 méthodes : combinaison d'une adresse et d'une horodate, dérivée d'un numéro de construteur ou d'un numéro unique affecté par un construceur, ou enfin, dérivée de l'adresse MAC d'une interface de réseau.
+
 
+
* 1 : Link-layer address plus time
+
* 2 : Vendor-assigned unique ID based on Enterprise Number
+
* 3 : Link-layer address
+
 
+
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ée qui selon le mode de construction, contient des types de valeur différents.
+
 
+
===== DUID construit à partir de l'adresse physique + horodate (1)(DUID-LLT) =====
+
Le champs type (2 octets) vaut 1. Deux octets contiennent le type de réseau physique. H’horodate est codée sur 4 octets, puis vient l’adresse physique. La longueur de l’adresse physique (adresse MAC) varie.
+
 
+
0                  1                  2                  3
+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|              1              |    hardware type (16 bits)    |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                time (32 bits)                |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.              link-layer address (variable length)            .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
   
 
   
Le choix de l’interface est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui à servi à le générer.
+
<nom> [ttl] IN AAAA <adresse>
  
Ce type de DUID est recommandé pour les ordinateurs de bureau, les ordinateurs portables, ou plus généralement pour tout équipement doté d'une mémoire non volatile où l’écriture est possible.
+
L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit :
  
Une interface d’administration doit permettre, sur chacun de ces équipements, que l’administrateur gère les conflits éventuels.
+
  ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1
 
+
=====DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN) =====
+
 
+
Un constructeur affecte ce type d’identificateur à un équipement. Ce DUID combine le numéro unique affecté à l’entreprise avec un identificateur de longueur variable, unique pour l’entreprise et défini par elle. Cet identificateur est généralement d’un entier non signé codé sur 32 bits. La structure du message est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| 2                            |      enterprise-number      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| enterprise-number (contd)    |                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
+
  .                       identifier                              .
+
.                     (variable length)                        .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.
+
 
+
===== 6.4.2. DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN)=====
+
Un constructeur affecte ce type d’identificateur à un équipement. Ce DUID combine le numéro unique affecté à l’entreprise avec un identificateur de longueur variable et unique pour l’entreprise. Cet identificateur est généralement d’un entier non signé codé sur 32 bits. La structure du message est la suivante :  
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|              3              |    hardware type (16 bits)    |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.              link-layer address (variable length)            .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.
+
 
+
Ce format est recommandé pour les équipements dépourvus de mémoire de stockage et qui ont une interface de réseau connectée en permanence au réseau (une imprimante réseau, par exemple).
+
 
+
==== 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.
+
 
+
Un client associe au moins une association d’identités à 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 (voir le principe de la renumérotation).
+
 
+
Les informations de configuration correspondent à une ou plusieurs adresses IPv6 et à leurs temporisations associées : T1 et T2. 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 temporaitres et 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'un écriture dans le fichier des baux. (à vérifier)
+
 
+
Le serveur DHCPv6, s'il est configuré pour cela effectuer des mises à jour dynamiques du service de noms de domaine.
+
 
+
=== Options ===
+
 
+
Chaque option est identifiée dans le paquet par un champ type d'option. Il permet l'interprétation des données transportées. Certaines options peuvent en contenir d'autres ou être structurée en plusieurs champs (voir Annexe 1).
+
 
+
Chaque option est codée en format TLV : Type, Longueur, Valeur, à savoir le type de l'option, la longueur en octet du champ valeur de l'option qui suit et le champ valeur du paramètre de configuration.
+
 
+
Le champ type de l'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.
+
 
+
La longueur totale en octet d'une option est donc 4 + longueur de la valeur du champ longueur de l'option.
+
 
+
 
+
{|
+
|+'''Options de DHCPv6'''
+
! Désignation || Code || Définition
+
|-style="background:silver"
+
|<tt>OPTION_CLIENTID</tt>
+
||1
+
||Identification du client
+
|-
+
|<tt>OPTION_SERVERID</tt>
+
||2
+
||Identification du serveur
+
|-style="background:silver"
+
|<tt>OPTION_IA_NA</tt>
+
||3
+
||Association d’identités pour les options d’adresse non temporaire
+
|-
+
|<tt>OPTION_IA_TA</tt>
+
||4
+
||Association d’identités pour les options d’adresse temporaire
+
|-style="background:silver"
+
|<tt>OPTION_IAADDR</tt>
+
||5
+
||Adresse associée à IA_NA ou IA_TA
+
|-
+
|<tt>OPTION_ORO</tt>
+
||6
+
||Identifie une liste d’options dans les messages échangés entre un client
+
|-style="background:silver"
+
|<tt>OPTION_PREFERENCE</tt>
+
||7
+
||Annonce la priorité du serveur DHCPv6 et comment gérer cette priorité au client.
+
|-
+
|<tt>OPTION_ELAPSED_TIME</tt>
+
||8
+
||Temps écoulé depuis le démarrage de la machine qui tente d’achever sa configuration.
+
|-style="background:silver"
+
|<tt>OPTION_RELAY_MSG</tt>
+
||9
+
||Transporte un message DHCPv6 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 que le serveur indique au client qu’il peut utiliser l’adresse individuelle (unicast) du serveur
+
|-
+
|<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, dans un message solicit, à un client de demander ce mode de fonctionnement. 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 à ne 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 les client et 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 annonce à un serveur si le client accepte ou refuse les messages reconfigure
+
|}
+
 
+
==Principe de l’allocation d’adresse IPv6 à un client en l’absence de relais ==
+
Un client relié au même lien que le serveur 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 a priori ce client ignore l'adresse ipv6 du serveur, le client DHCPv6 envoie toujours (c'est le mode de fonctionnement par défaut) ce message à l’adresse de diffusion sélective  ALL_DHCP_And_ Relay_Agent.
+
 
+
Les serveurs capables d’allouer des adresses au client répondent avec un message DHCPv6 ADVERTISE.
+
 
+
Au cas où plusieurs serveurs DHCPV6 configurés seraient 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. le client émet alors un message request. Il envoie ce message à l’adresse de diffusion sélective  ALL_DHCP_And_ Relay_Agent. Ainsi tous les serveurs qui ont répondu à la demande du client savent si leur offre a ou non été retenue.
+
 
+
le serveur dont l'offre à été retenue, et lui seul, renvoie un message REPLY au client.
+
 
+
La figure ci-dessous résume les messages DHCPv6 échangés dans ce cas.
+
 
+
 
+
**** Animation ****
+
Client Serveur
+
                      Solicit
+
        ---------------------------->
+
                    Advertise
+
        <----------------------------
+
                      Request
+
        ---------------------------->
+
                      Reply
+
        <-------------------------
+
 
+
 
+
 
+
=== Recherche des serveurs DHCPv6 par le client DHCPv6 ===
+
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 disponible.
+
 
+
Il s’adresse localement au protocole UDP sur le port local du client DHCPv6 pour expédier ce message vers le port UDP destination du serveur. Comme à ce stade le client DHCPv6 ignore l’adresse IPv6 du serveur, il fournit à UDP l’adresse IPv6 de diffusion sélective (multicast) réservée ALL_DHCPV6_Relay_Agents_and_Servers 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 à transmettre à la couche IPv6.
+
 
+
IPv6 fabrique l’en-tête du datagramme qui transporte le message DHCPv6 encapsulé dans UDP. Comme notre client n’a qu’une interface, celle-ci est associée à la route par défaut. 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 empruntera la route par défaut. L’adresse IPv6 source utilisée ici est donc celle 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. Ceci permet d’utiliser, au niveau 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.
+
 
+
Le client DHCPv6 envoie donc la trame Ethernet sur le lien, vers le serveur DHCPv6.
+
 
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 3c 11 01 fe 80 00 00 00 00 00 00  `....<..........
+
0020  0a 00 27 ff fe 9b a1 9b ff 02 00 00 00 00 00 00  ..'.............
+
0030  00 00 00 00 00 01 00 02 02 22 02 23 00 3c 6e ef  .........".#.<n.
+
0040  01 4d 54 a4 00 01 00 0e 00 01 00 01 1c 77 78 81  .MT..........wx.
+
0050  08 00 27 9b a1 9b 00 03 00 0c 00 00 00 01 ff ff  ..'.............
+
0060  ff ff ff ff ff ff 00 08 00 02 00 00 00 06 00 04  ................
+
0070  00 17 00 18                                      ....
+
 
+
Indice
+
Au niveau DHCPv6 la structure du message est la suivante :
+
type de message, identificateur de transaction,  options (
+
Identification du client
+
Association d’identités pour adresse non temporaire
+
Temps écoulé depuis l’activation du processus DHCPv6 client
+
paramètres de configuration du réseau demandés)
+
 
+
Question.
+
 
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ?
+
 
+
Quelles sont la valeur et la signification du champ type Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction de chacun des champs du protocole transporté par Ethernet ?
+
+
Quel est le protocole transporté par le protocole précédent ?
+
 
+
Quelles sont les valeurs des informations importantes pour interpréter les messages transportés par le protocole de transport ?
+
 
+
Quels sont enfin le protocole, le message, la valeur et la signification de chacun des champs  de ce protocole ?
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0).
+
Réponse .
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
+
 
+
=== Emission du message ADVERTISE  du serveur DHCPv6 vers le client DHCPv6 ===
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd  ........'.E.....
+
0010  60 00 00 00 00 e6 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe 1e 45 17 fe 80 00 00 00 00 00 00  ..'...E.........
+
0030  0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 e6 1f e4  ..'......#."....
+
0040  02 4d 54 a4 00 03 00 84 00 00 00 01 00 00 07 d0  .MT.............
+
0050  00 00 0b b8 00 05 00 18 20 01 0d b8 33 0f a0 d1  ........ ...3...
+
0060  00 00 00 00 00 00 00 bd 00 00 0e 10 00 00 1c 20  ...............
+
0070  00 0d 00 58 00 00 31 20 61 64 64 72 65 73 73 20  ...X..1 address
+
0080  67 72 61 6e 74 65 64 2e 20 59 6f 75 20 6d 61 79  granted. You may
+
0090  20 69 6e 63 6c 75 64 65 20 49 41 41 44 44 52 20    include IAADDR
+
00a0  69 6e 20 49 41 20 6f 70 74 69 6f 6e 2c 20 69 66  in IA option, if
+
00b0  20 79 6f 75 20 77 61 6e 74 20 74 6f 20 70 72 6f    you want to pro
+
00c0  76 69 64 65 20 61 20 68 69 6e 74 2e 00 02 00 0e  vide a hint.....
+
00d0  00 01 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 01  .....wu:..'](k..
+
00e0  00 0e 00 01 00 01 1c 77 78 81 08 00 27 9b a1 9b  .......wx...'...
+
00f0  00 07 00 01 07 00 17 00 10 20 01 0d b8 33 0f a0  ......... ...3..
+
0100  d1 00 00 00 00 00 00 00 53 00 18 00 11 03 74 70  ........S.....tp
+
0110  74 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00        t.example.com.
+
 
+
 
+
Indice.
+
 
+
Message DHCPv6 : type de message, identificateur de transaction (
+
Association d’identités pour adresse non temporaire
+
Adresse IP
+
statut
+
Identification du serveur
+
Identification du client
+
Priorité du serveur
+
Paramètres de configuration du réseau)
+
 
+
Question.
+
 
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ? Quelles sont la valeur et la signification du champ ype Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction des adresses du protocole transporté par Ethernet
+
 
+
Quel est le protocole transporté par le protocole précédent ? quelles sont les valeurs des informations importantes pour interpréter les messages transporté par le protocole de transport ?
+
 
+
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
+
 
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 1).
+
Réponse.
+
 
+
=== Emission du message REQUEST du client DHCPv6 vers le serveur DHCPv6 ===
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 6a 11 01 fe 80 00 00 00 00 00 00  `....j..........
+
0020  0a 00 27 ff fe 9b a1 9b ff 02 00 00 00 00 00 00  ..'.............
+
0030  00 00 00 00 00 01 00 02 02 22 02 23 00 6a 5f e6  .........".#.j_.
+
0040  03 b1 4a a1 00 01 00 0e 00 01 00 01 1c 77 78 81  ..J..........wx.
+
0050  08 00 27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff  ..'......(......
+
0060  ff ff ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f  .......... ...3.
+
0070  a0 d1 00 00 00 00 00 00 00 bd 00 00 0e 10 00 00  ................
+
0080  1c 20 00 06 00 04 00 17 00 18 00 02 00 0e 00 01  . ..............
+
0090  00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02  ...wu:..'](k....
+
00a0  00 00                                            ..
+
 
+
Indice
+
Message DHCPv6 : type de message, identificateur de transaction (
+
Association d’identités pour adresse non temporaire
+
Adresse IP
+
statut
+
Identification du serveur
+
Identification du client
+
Priorité du serveur
+
Paramètres de configuration du réseau)
+
 
+
Question.
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ? Quelles sont la valeur et la signification du champ type Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction des adresses du protocole transporté par Ethernet
+
 
+
Quel est le protocole transporté par le protocole précédent ? quelles sont les valeurs des informations importantes pour interpréter les messages transporté par le protocole de transport ?
+
 
+
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
+
 
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0)
+
Réponse.
+
 
+
=== Emission du message REPLY du serveur DHCPv6 vers le client DHCPv6 ===
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd  ........'.E.....
+
0010  60 00 00 00 00 ac 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe 1e 45 17 fe 80 00 00 00 00 00 00  ..'...E.........
+
0030  0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 ac c0 dd  ..'......#."....
+
0040  07 b1 4a a1 00 03 00 4a 00 00 00 01 00 00 07 d0  ..J....J........
+
0050  00 00 0b b8 00 05 00 18 20 01 0d b8 33 0f a0 d1  ........ ...3...
+
0060  00 00 00 00 00 00 00 bd 00 00 0e 10 00 00 1c 20  ...............
+
0070  00 0d 00 1e 00 00 41 6c 6c 20 61 64 64 72 65 73  ......All addres
+
0080  73 65 73 20 77 65 72 65 20 61 73 73 69 67 6e 65  ses were assigne
+
0090  64 2e 00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00  d..........wu:..
+
00a0  27 5d 28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81  '](k.........wx.
+
00b0  08 00 27 9b a1 9b 00 07 00 01 07 00 17 00 10 20  ..'............
+
00c0  01 0d b8 33 0f a0 d1 00 00 00 00 00 00 00 53 00  ...3..........S.
+
00d0  18 00 11 03 74 70 74 07 65 78 61 6d 70 6c 65 03  ....tpt.example.
+
00e0  63 6f 6d 00                                      com.
+
 
+
indice
+
Message DHCPv6 REPLY, identificateur de transaction (
+
Association d’identités pour adresse non temporaire
+
Adresse IPv6
+
Paramètres de configuration demandés
+
Identification du serveur
+
Identification du client
+
Temps écoulé depuis l’activation du processus DHCPv6 client)
+
 
+
Question. Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ? Quelles sont la valeur et la signification du champ type Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction des adresses du protocole transporté par Ethernet
+
 
+
Quel est le protocole transporté par le protocole précédent ? quelles sont les valeurs des informations importantes pour interpréter les messages transporté par le protocole de transport ?
+
 
+
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
+
 
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0) Réponse.
+
 
+
== Principe de l’allocation d’adresse IPv6 à un client en présence d’un relais DHCPv6 ==
+
Lorsque le client se trouve derrière un routeur par rapport au serveur DHCPv6, ce dernier ignore sur quel lien se trouve le client. Il ne peut alors pas allouer d’adresse correspondant au lien du client puisqu'il ignore le ou les préfixes à 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...).
+
 
+
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 au serveur. Le relais DHCPv6 envoie le message RELAY-FORWARD 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 unicast du serveur. Il faut, bien entendu dans ce cas, adapter la configuration du serveur et des relais en fonction du type d’adresse 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 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’interface par laquelle il réexpédie au serveur son message relay forward.
+
Rappelons que le message du client est recopié dans l'option message relayé 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 serveur DHCPv6 reçoit le message RELAY-FORWARD du dernier relais DHCPV6, il trouve dans l'en-tête de ce message 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-FORWARD du relais précédent.
+
 
+
Le chemin inverse n’est par conséquent pas difficile à calculer. Le serveur DHCPv6 peut donc ainsi faire parvenir sa réponse au client.
+
 
+
Client             Relais                   Serveur
+
.        SOLICIT
+
---------------------->
+
.                   Relay-forward (solicit)
+
                        ----------------------------->
+
.                  Relay-reply (advertise)
+
                        <-----------------------------
+
.    Advertise
+
<----------------------
+
.        request
+
---------------------->
+
.                   Relay-forward (request)
+
                        ----------------------------->
+
.                    Relay-reply (Reply)
+
                        <-----------------------------
+
. Reply
+
<----------------------
+
 
+
Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie (DAD) que l'adresse ipv6 allouée n'est pas déjà en service. Il configure alors ses interfaces de réseau. L'utilisateur qui travaille sur le client DHCPv6 peut alors accéder au réseau. Le processus DHCPv6 devient inactif jusqu'à ce que l'utilisateur qui travaille sur le client DHCPv6 ferme sa session et arrête le client. Le processus DHCPv6 client se réactive alors pour libérer (release) l'adresse IPv6 allouée.
+
=== Détail des messages DHCPv6 ===
+
==== SOLICIT ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 3c 11 01 fe 80 00 00 00 00 00 00  `....<..........
+
0020  0a 00 27 ff fe 9b a1 9b ff 02 00 00 00 00 00 00  ..'.............
+
0030  00 00 00 00 00 01 00 02 02 22 02 23 00 3c 91 07  .........".#.<..
+
0040  01 45 32 94 00 01 00 0e 00 01 00 01 1c 77 78 81  .E2..........wx.
+
0050  08 00 27 9b a1 9b 00 03 00 0c 00 00 00 01 ff ff  ..'.............
+
0060  ff ff ff ff ff ff 00 08 00 02 00 00 00 06 00 04  ................
+
0070  00 17 00 18                                      ....
+
 
+
Indice Au niveau DHCPv6 la structure du message est la suivante : type de message, identificateur de transaction, options (Identification du client Association d’identités pour adresse non temporaire Temps écoulé depuis l’activation du processus DHCPv6 client paramètres de configuration du réseau demandés)
+
 
+
Question.
+
 
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ?
+
 
+
Quelles sont la valeur et la signification du champ type Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction de chacun des champs du protocole transporté par Ethernet ?
+
 
+
Quel est le protocole transporté par le protocole précédent ?
+
 
+
Quelles sont les valeurs des informations importantes pour interpréter les messages transportés par le protocole de transport ?
+
 
+
Quels sont enfin le protocole, le message, la valeur et la signification de chacun des champs de ce protocole ?
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0). Réponse .
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
+
 
+
==== RELAY-FORWARD(SOLICIT) ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 8e e4 bd 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 6a 11 01 20 01 0d b8 33 0f a0 d1  `....j.. ...3...
+
0020  00 00 00 00 00 00 01 97 ff 05 00 00 00 00 00 00  ................
+
0030  00 00 00 00 00 01 00 03 02 23 02 23 00 6a 6a 54  .........#.#.jjT
+
0040  0c 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00  .. ...3.........
+
0050  01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b  ............'...
+
0060  a1 9b 00 12 00 04 00 00 13 9c 00 09 00 34 01 45  .............4.E
+
0070  32 94 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00  2..........wx...
+
0080  27 9b a1 9b 00 03 00 0c 00 00 00 01 ff ff ff ff  '...............
+
0090  ff ff ff ff 00 08 00 02 00 00 00 06 00 04 00 17  ................
+
00a0  00 18                                            ..
+
 
+
==== RELAY-REPLY(ADVERTISE) ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 00 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd  ........'.E.....
+
0010  60 00 00 00 00 eb 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe 1e 45 17 20 01 0d b8 33 0f a0 d1  ..'...E. ...3...
+
0030  00 00 00 00 00 00 01 97 02 23 02 23 00 eb d2 3b  .........#.#...;
+
0040  0d 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00  .. ...3.........
+
0050  01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b  ............'...
+
0060  a1 9b 00 12 00 04 00 00 13 9c 00 09 00 b5 02 45  ...............E
+
0070  32 94 00 03 00 84 00 00 00 01 00 00 0e 10 00 00  2...............
+
0080  15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 00 00  ...... ...3.....
+
0090  00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 00 0d  ........Q.......
+
00a0  00 58 00 00 31 20 61 64 64 72 65 73 73 20 67 72  .X..1 address gr
+
00b0  61 6e 74 65 64 2e 20 59 6f 75 20 6d 61 79 20 69  anted. You may i
+
00c0  6e 63 6c 75 64 65 20 49 41 41 44 44 52 20 69 6e  nclude IAADDR in
+
00d0  20 49 41 20 6f 70 74 69 6f 6e 2c 20 69 66 20 79    IA option, if y
+
00e0  6f 75 20 77 61 6e 74 20 74 6f 20 70 72 6f 76 69  ou want to provi
+
00f0  64 65 20 61 20 68 69 6e 74 2e 00 02 00 0e 00 01  de a hint.......
+
0100  00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 01 00 0e  ...wu:..'](k....
+
0110  00 01 00 01 1c 77 78 81 08 00 27 9b a1 9b 00 07  .....wx...'.....
+
0120  00 01 07                                          ...
+
 
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ?
+
 
+
Quelles sont la valeur et la signification du champ type Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction de chacun des champs du protocole transporté par Ethernet ?
+
 
+
Quel est le protocole transporté par le protocole précédent ?
+
 
+
Quelles sont les valeurs des informations importantes pour interpréter les messages transportés par le protocole de transport ?
+
 
+
Quels sont enfin le protocole, le message, la valeur et la signification de chacun des champs de ce protocole ?
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 0). Réponse .
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole.
+
 
+
==== ADVERTISE ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 a5 cd 3d 00 00 86 dd  ........'..=....
+
0010  60 00 00 00 00 bd 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe a5 cd 3d fe 80 00 00 00 00 00 00  ..'....=........
+
0030  0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 bd 71 be  ..'......#."..q.
+
0040  02 45 32 94 00 03 00 84 00 00 00 01 00 00 0e 10  .E2.............
+
0050  00 00 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2  ........ ...3...
+
0060  00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00  ..........Q.....
+
0070  00 0d 00 58 00 00 31 20 61 64 64 72 65 73 73 20  ...X..1 address
+
0080  67 72 61 6e 74 65 64 2e 20 59 6f 75 20 6d 61 79  granted. You may
+
0090  20 69 6e 63 6c 75 64 65 20 49 41 41 44 44 52 20    include IAADDR
+
00a0  69 6e 20 49 41 20 6f 70 74 69 6f 6e 2c 20 69 66  in IA option, if
+
00b0  20 79 6f 75 20 77 61 6e 74 20 74 6f 20 70 72 6f    you want to pro
+
00c0  76 69 64 65 20 61 20 68 69 6e 74 2e 00 02 00 0e  vide a hint.....
+
00d0  00 01 00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 01  .....wu:..'](k..
+
00e0  00 0e 00 01 00 01 1c 77 78 81 08 00 27 9b a1 9b  .......wx...'...
+
00f0  00 07 00 01 07                                    .....
+
 
+
Indice.
+
 
+
Message DHCPv6 : type de message, identificateur de transaction ( Association d’identités pour adresse non temporaire Adresse IP statut Identification du serveur Identification du client Priorité du serveur Paramètres de configuration du réseau)
+
 
+
Question.
+
 
+
Dans la capture de trame Ethernet qui précède, quelles sont les valeurs des adresses Ethernet destination et source, quelles sont leur type, quelle est la fonction de chacune de ces adresses ? Quelles sont la valeur et la signification du champ ype Ethernet ?
+
 
+
Quelles sont les valeurs, le type et la fonction des adresses du protocole transporté par Ethernet
+
 
+
Quel est le protocole transporté par le protocole précédent ? quelles sont les valeurs des informations importantes pour interpréter les messages transporté par le protocole de transport ?
+
 
+
quels sont, enfin le protocole, le message, le type du message et les différentes informations transportées par ce protocole de transport ?
+
 
+
 
+
Pour chacun des protocoles transportés, donnez la valeur et l’interprétation de chaque champs vous pouvez vous aider d’un analyseur de protocole, Wireshark, par exemple.
+
 
+
A quel déplacement se trouve le message applicatif (par rapport au premier octet de la trame Ethernet, sachant que le premier octet a le numéro 1). Réponse.
+
 
+
==== request ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 02 00 01 00 06 08 00 27 9b a1 9b 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 6a 11 01 fe 80 00 00 00 00 00 00  `....j..........
+
0020  0a 00 27 ff fe 9b a1 9b ff 02 00 00 00 00 00 00  ..'.............
+
0030  00 00 00 00 00 01 00 02 02 22 02 23 00 6a 80 cf  .........".#.j..
+
0040  03 ad 5f 37 00 01 00 0e 00 01 00 01 1c 77 78 81  .._7.........wx.
+
0050  08 00 27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff  ..'......(......
+
0060  ff ff ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f  .......... ...3.
+
0070  a0 d2 00 00 00 00 00 00 00 ed 00 01 51 80 00 02  ............Q...
+
0080  a3 00 00 06 00 04 00 17 00 18 00 02 00 0e 00 01  ................
+
0090  00 01 1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02  ...wu:..'](k....
+
00a0  00 00                                            ..
+
 
+
==== Relay-forward (request) ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 8e e4 bd 00 00 86 dd  ........'.......
+
0010  60 00 00 00 00 98 11 01 20 01 0d b8 33 0f a0 d1  `....... ...3...
+
0020  00 00 00 00 00 00 01 97 ff 05 00 00 00 00 00 00  ................
+
0030  00 00 00 00 00 01 00 03 02 23 02 23 00 98 59 ee  .........#.#..Y.
+
0040  0c 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00  .. ...3.........
+
0050  01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b  ............'...
+
0060  a1 9b 00 12 00 04 00 00 13 9c 00 09 00 62 03 ad  .............b..
+
0070  5f 37 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00  _7.........wx...
+
0080  27 9b a1 9b 00 03 00 28 00 00 00 01 ff ff ff ff  '......(........
+
0090  ff ff ff ff 00 05 00 18 20 01 0d b8 33 0f a0 d2  ........ ...3...
+
00a0  00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00  ..........Q.....
+
00b0  00 06 00 04 00 17 00 18 00 02 00 0e 00 01 00 01  ................
+
00c0  1c 77 75 3a 08 00 27 5d 28 6b 00 08 00 02 00 00  .wu:..'](k......
+
 
+
Indice.
+
 
+
Message DHCPv6 : type de message, nombre de sauts, adresse du lien (côté client DHCPv6), adresse du pair, (options : identificateur d'interface, message relayé (type de message, identificateur de transaction, identificateur de client (DUID, typede DUID, type de réseau physique, adresse MAC), association d'identités pour adresse non temporaire (identificateur d'association d'identité, T1 durée de vie en mode préféré, T2 durée de vie totale, temps écoulé, paramètres de configuration du réseau demandés),
+
 
+
==== Relay-reply (Reply) ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 00 00 01 00 06 08 00 27 1e 45 17 00 00 86 dd  ........'.E.....
+
0010  60 00 00 00 00 b1 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe 1e 45 17 20 01 0d b8 33 0f a0 d1  ..'...E. ...3...
+
0030  00 00 00 00 00 00 01 97 02 23 02 23 00 b1 3c c5  .........#.#..<.
+
0040  0d 00 20 01 0d b8 33 0f a0 d2 00 00 00 00 00 00  .. ...3.........
+
0050  01 97 fe 80 00 00 00 00 00 00 0a 00 27 ff fe 9b  ............'...
+
0060  a1 9b 00 12 00 04 00 00 13 9c 00 09 00 7b 07 ad  .............{..
+
0070  5f 37 00 03 00 4a 00 00 00 01 00 00 0e 10 00 00  _7...J..........
+
0080  15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2 00 00  ...... ...3.....
+
0090  00 00 00 00 00 ed 00 01 51 80 00 02 a3 00 00 0d  ........Q.......
+
00a0  00 1e 00 00 41 6c 6c 20 61 64 64 72 65 73 73 65  ....All addresse
+
00b0  73 20 77 65 72 65 20 61 73 73 69 67 6e 65 64 2e  s were assigned.
+
00c0  00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00 27 5d  .........wu:..']
+
00d0  28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81 08 00  (k.........wx...
+
00e0  27 9b a1 9b 00 07 00 01 07                        '........
+
 
+
==== Reply ====
+
La trame Ethernet ci-dessous a été capturée à l'aide d'un analyseur de protocole. La première colonne indique, en hexadécimal, le numéro du premier octet de la ligne. La super colonne centrale constitue en fait la juxtaposition de la valeur hexadécimale de 16 octets (un octet par colonne et 16 octets sur une ligne). La dernière colonne présente l'interprétation ASCII des caractères hexadécimaux de la supercolonne.
+
 
+
0000  00 04 00 01 00 06 08 00 27 a5 cd 3d 00 00 86 dd  ........'..=....
+
0010  60 00 00 00 00 83 11 40 fe 80 00 00 00 00 00 00  `......@........
+
0020  0a 00 27 ff fe a5 cd 3d fe 80 00 00 00 00 00 00  ..'....=........
+
0030  0a 00 27 ff fe 9b a1 9b 02 23 02 22 00 83 dc 0d  ..'......#."....
+
0040  07 ad 5f 37 00 03 00 4a 00 00 00 01 00 00 0e 10  .._7...J........
+
0050  00 00 15 18 00 05 00 18 20 01 0d b8 33 0f a0 d2  ........ ...3...
+
0060  00 00 00 00 00 00 00 ed 00 01 51 80 00 02 a3 00  ..........Q.....
+
0070  00 0d 00 1e 00 00 41 6c 6c 20 61 64 64 72 65 73  ......All addres
+
0080  73 65 73 20 77 65 72 65 20 61 73 73 69 67 6e 65  ses were assigne
+
0090  64 2e 00 02 00 0e 00 01 00 01 1c 77 75 3a 08 00  d..........wu:..
+
00a0  27 5d 28 6b 00 01 00 0e 00 01 00 01 1c 77 78 81  '](k.........wx.
+
00b0  08 00 27 9b a1 9b 00 07 00 01 07                  ..'........
+
 
+
== libération de l'adresse IPv6 par le client DHCPv6 avec présence d'un relais ==
+
Le processus d'arrêt normal du client DHCPv6 inclut la libération de l'adresse ipv6 allouée par le serveur. La figure ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais.
+
 
+
 
+
Client             Relais                   Serveur
+
.        RELEASE
+
---------------------->
+
.                   Relay-forward (RELEASE)
+
                        ----------------------------->
+
.                    Relay-reply (REPLY)
+
                        <-----------------------------
+
.        REPLY
+
<----------------------
+
+
La figure ci-dessous présente la libération de l'adresse IPv6 en l'absence de relais;
+
 
+
Client             Serveur
+
.        RELEASE
+
---------------------->
+
 
+
.        REPLY
+
<---------------------
+
 
+
== 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. Elle utilise le protocole DHCPv6 pour assurer la délégation de préfixe et 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éfixe (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. Lorsque ces deux routeurs ne se trouvent pas sur le même réseau, des relais DHCPv6 intrviennent, comme dans le cas de l'allocation d'dresses. Le fonctionnement des relais est inchangé. Le fonctionnement se fait sans relais lorsque les routeurs délégataire et demandeur sont sur le même lien.
+
 
+
Ces options permettenr 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équé à un routeur demandeur. Cette option peut apparaître plusieurs fois dans une 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) (ISP : Internet service Provider) qui alloue un préfixe au routeur d'accès d'un client (CPE : customer Premise Equipment) qui relie un réseau interne au réseau du FAI. La figure ci-dessous présente un exemple où la délégation de préfixe à états est possible.
+
 
+
 
+
                ______________________                \
+
              /                      \                \
+
              | ISP core network      |                \
+
              \__________ ___________/                  |
+
                          |                              |
+
                  +-------+-------+                      |
+
                  | Aggregation  |                      | ISP
+
                  | device        |                      | network
+
                  | (delegating  |                      |
+
                  |    router)  |                      |
+
                  +-------+-------+                      |
+
                          |                              /
+
                          |DSL to subscriber            /
+
                          |premises                    /
+
                          |
+
                  +------+------+                      \
+
                  |    CPE      |                      \
+
                  | (requesting |                        \
+
                  |    router)  |                        |
+
                  +----+---+----+                        |
+
                        |  |                              | Subscriber
+
  ---+-------------+-----+- -+-----+-------------+---    | network
+
      |            |              |            |        |
+
+----+-----+ +-----+----+    +----+-----+ +-----+----+  |
+
|Subscriber| |Subscriber|    |Subscriber| |Subscriber|  /
+
|    PC    | |    PC    |    |    PC    | |    PC    |  /
+
+----------+ +----------+    +----------+ +----------+ /
+
 
+
La délégation de préfixe facilite également la renumérotation. Les préfixes sont censés avoir une grande diré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.
+
 
+
Notez que l'utilisation du préfixe alloué est impossible sur le lien donnant accès au routeur délégataire.
+
 
+
Deux autres options [RFC 6603],permettent d'exclure un seul préfixe pour l'affecter au lien donnant accès au routeur délégataire. Certains réseaux mobiles présentent cette contrainte pour pouvoir agréger les routes (vers le routeur et le réseau interne.
+
 
+
=== Structure de l'option d'association d'identités pour la délégation de préfixes [RFC 3633, RFC 7550] ===
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        OPTION_IA_PD (25)    |          option-length        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                        IAID (4 octets)                        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                              T1  (secondes)                  |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                              T2  (secondes                  |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                        IA_PD-options                        .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
Les temporisations T1 et T2 représentent en secondes les durées de vie du préfixe en mode préféré et totale.
+
 
+
=== option de préfixe d'association d'identités pour la délégation de préfixe ===
+
L'option de préfixe d'association d'identités pour la délégation de préfixe (IA_PD PRefix) contient les préfixes associés à une IA_PD. Cette option est incluse dans l'option IA_PD.
+
 
+
La structure de cette otpion est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_IAPREFIX(26)      |          option-length      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                        preferred-lifetime                    |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                          valid-lifetime                      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| prefix-length |                                              |
+
+-+-+-+-+-+-+-+-+            IPv6 prefix                      |
+
|                            (16 octets)                      |
+
|                                                              |
+
|                                                              |
+
|                                                              |
+
|                                                              |
+
|                                                              |
+
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|              |                                              .
+
+-+-+-+-+-+-+-+-+                                              .
+
.                            IAprefix-options                  .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Principe de l'allocation de préfixe à états sans relai ===
+
Routeur Routeur
+
demandeur                                      délégataire  <- préfixes à   
+
                                                                déléguer
+
                            Solicit (IA_PD)
+
                    ---------------------------->
+
                            Advertise (IAPD)
+
  Préfixes alloués  <----------------------------
+
                              Request (IAPD)
+
                    ---------------------------->
+
                              Reply (IA_PD)
+
                    <-------------------------
+
Annonce des préfixes délégués
+
dans des annonces de routeur,
+
sur les interfaces (internes)
+
concernées.
+
 
+
Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT contenant une 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.
+
 
+
=== Principe de l'allocation de préfixe à états avec relai ===
+
 
+
Routeur             Relais                   Serveur
+
demandeur                                                      préfixes à
+
                                                                déléguer
+
 
+
.      SOLICIT (IA_PD)
+
---------------------->
+
.                         Relay-forward (SOLICIT (IA_PD))
+
                                --------------------------->
+
.                        Relay-reply (ADVERTISE (IA_PD))
+
                                <---------------------------
+
.    ADVERTISE (IA_PD)
+
<----------------------
+
+
Le routeur demandeur peut
+
annoncer les préfixes délégués
+
sur les interfaces de réseau
+
appropriées.
+
 
+
== Conclusion ==
+
 
+
DHCPv6 est un protocole de niveau application. Il fonctionne en mode client serveur. Les messages échangés transportent l'identité de l'émetteur (DUID), celui 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, ou au contraire en laissant aux clients la possibilité deles prendre en compte, lorsqu'ils le souhaitent.
+
 
+
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 ou ceux des serveurs ne sont jamais modifiés.
+
 
+
Tous les paramètres de configuration du réseau sont transportés dans des options ce qui fait de DHCPv6 un protocole extensible.
+
 
+
Initialement, ni la délégation de préfixe, ni l'exclusion de préfixe n'existaient pas. Il a suffit de définir deux options et leur gestion en émission et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6. Ceci a impliqué [RFC 7550] des modifications pour clarifier ou préciser la spécification de DHCPv6 [RFC 3315].
+
 
+
== Annexe 1. Structure des options du protocole DHCPv6 ==
+
La structure générale des options est la suivante. Elle correspond à un codage TLV : type, longueur, valeur.
+
 
+
Le type ou code est un entier non signé. Il précise quelle est l’option. La longueur de l’option précise la taille en octet du champs de données de l’option. Le champs type de l'option en est exclus. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.
+
 
+
la portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'un association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.
+
 
+
La structure générale d'une option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| option-code                  |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                        option-data                          |
+
|                    (option-len octets)                        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
+
=== Option d'identification du client ===
+
L'option d'identification du client (Client Identifier Option) transporte le DUID (DHCPv6 User Identification) du client dans les messages DHCPv6 échangés entre client et serveur.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        OPTION_CLIENTID      |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                            DUID                              .
+
.                          (variable length                    .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option identification du serveur (Server Identification Option)===
+
L'option identification du serveur (Server Identification Option) transporte le DUID (DHCPv6 User Identification) du serveur dans les messages DHCPv6 échangés entre client et serveur.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| OPTION_SERVERID                | option-len                  |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                              DUID                            .
+
.                        (variable length)                    .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option association d’identité pour les adresses non temporaires ===
+
L'Option association d’identité pour les adresses non temporaires (option IA_NA : Identity Association for Non Temporary Addresses) inclut les paramètres de cette association et les adresses non temporaires associées. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6.
+
 
+
Cette association transporte un identificateur d'IA_NA, les temporisations T1 durée de vie préférée d'une adresse et T2 durée de vie maximum d'une adresse et les options de cette association, par exemple la liste des options d'adresse spécifiques de cette association.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|            OPTION_IA_NA      |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                      IAID (4 octets)                          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                              T1                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                              T2                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
.                          IA_NA-options                        .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option d'association d’identité pour les adresses temporaires ===
+
L'option d'association d’identité pour les adresses temporaires (option IA_TA : Identity Association for Temporary Addresses) inclut les paramètres de cette association et au plus une adresses temporaires associées par préfixe autorisé sur le lien du client. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6. Une option statut indique l'état de toute opération impliquant cette option.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|            OPTION_IA_TA      |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                        IAID (4 octets)                      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
.                        IA_TA-options                        .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option d’adresse d'association d'identités ===
+
L'option d'adresse'association d'identités (IA Address Option) spécifie une adresse IPv6 associée à une association d'identités IA_NA ou IA_TA. Elle  apparaît dans le champ d'option d'une association d'identités pour adresse non temporaire ou temporaire. Une option statut indique l'état de toute opération impliquant cette adresse.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|          OPTION_IAADDR        |        option-len            |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
|                        IPv6 address                          |
+
|                                                              |
+
|                                                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                    preferred-lifetime                        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                      valid-lifetime                          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                      IAaddr-options                          .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option de demande d’options ===
+
L'option de demande d'option (Options Request Option) identifie la liste des options demandées par le client ou fournies ou cconcernées pour le serveur.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|          OPTION_ORO          |        option-len            |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|    requested-option-code-1    |    requested-option-code-2    |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                              ...                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option de priorité (du serveur) ===
+
L'option de priorité (Preference Option) indique la priorité du serveur  au client.
+
 
+
Un client choisit le serveur de priorité la plus élevée. En cas d'égalité des priorités, il choisit le serveur de priorité la plus élevée qui lui propose la meilleure offre. Il peut ne pas choisir l'offre du serveur le plus prioritaire. Le choix repose alors sur l'adéquation de l'offre.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        OPTION_PREFERENCE      |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|  pref-value  |
+
+-+-+-+-+-+-+-+-+
+
 
+
 
+
=== Option temps écoulé (depuis le début d'un échange) ===
+
L'option temps écoulé mesure le temps écoulé (Elapsed Time Option) depuis l'émission du premier message d'un échange DHCPv6 inachevé. Cette option vaut 0 dans le premier message d'un échange.
+
 
+
Serveurs et agents utilisent la valeur de cette option pour déterminer leur façon de traiter le message DHCPv6 correspondant. La valeur ffff en hexadécimal (0xffff) représente une durée supérieure à la plus grande durée représentable.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_ELAPSED_TIME    |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        elapsed-time          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
 
+
+
=== Option message relayé ===
+
L'option message relayé (RELAY Message Option) contient le message DHCPv6 relayé dans un message RELAY-FORWARD ou RELAY-REPLY.
+
 
+
Le message relayé, dans le cas d'un message qui transite du client vers le serveur, est soit le message DHCPv6 du client (premier relais), soit le message RELAY-FORWARD du relais précédent (du deuxième relais au dernier).
+
 
+
Le message relayé dans le cas d'un message qui transite du serveur vers le client est, soit le message REPLY du serveur (premier relais), soit le message RELAY-REPLY du relais précédent (du deuxième relais au dernier).
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_RELAY_MSG        |            option-len        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
.                      DHCP-relay-message                      .
+
.                                                              .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option d’authentification ===
+
L'option d'authentification (Authetication Option) transporte une information d'authentification. Cette information authentifie l'identité de l'émetteur et l'intégrité du message DHCPv6. Cette option fournit un environnement qui prend en compte différents protocoles d'authentification, ce qui permettra d'en prendre en compte de nouveaux.
+
 
+
Cette option décrit donc le protocole d'authentification utilisé, la méthode de protection contre le rejeu, l'algorithme de génération du condensé (MAC : Message Authentification Code) qui authentifie le message, et bien entendu la valeur du condensé (128 bits, pa exemple).
+
 
+
Rappel : le principe de l'authentification consiste à calculer un condensé de taille fixe qui ne dépend que de l'information prise en compte (le message DHCPv6, par exemple) en utilisant un algorithme tel que deux informations différentes produisent très probablement des condensés différents. La comparaison des condensés reçu et calculé par le récepteur permet de décider si les données reçues sont ou ne sont pas acceptables. Si ces condensés sont ientiques, l'information est acceptable. Elle ne l'est pas sinon.
+
 
+
La sécurisation des échanges DHCPv6 entre serveurs et relais adjacents utilise IPsec.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|          OPTION_AUTH          |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|  protocol    |  algorithm  |      RDM    |              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |
+
|                                                              |
+
| replay detection (64 bits)                    +-+-+-+-+-+-+-+-+
+
|                                              |  auth-info  |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |
+
.                  authentication information                  .
+
.                        (variable length)                      .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
+
=== Option d’utilisation de l'adresse individuelle du serveur ===
+
L'option d'utilisation de l'adresse individuelle du serveur (Server Unicast Option), qu'émet un serveur, autorise le client DHCPv6 qui reçoit cette option à échanger avec le serveur en utilisant son adresse individuelle au lieu de l'adresse de diffusion sélective All_DHCP_Relay_Agents_and_Servers address.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|          OPTION_UNICAST      |          option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                                                              |
+
|                      server-address                          |
+
|                                                              |
+
|                                                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
 
+
+
=== Option de code d’état ===
+
L'option code d'état Status Code Option) renvoie une indication d'état relative au message DHCPv6 ou à l'option dans laquelle cette option apparaît. L'omission du code d'état dans un message ou dans une option où son utilisation est possible signifie succès (success).
+
 
+
La structure de cette option est la suivante :
+
 
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_STATUS_CODE      |            option-len        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        status-code            |                              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
+
.                                                              .
+
.                        status-message                        .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
L'annexe 2 présente les valeurs des différents codes d'état.
+
 
+
=== Option de Validation rapide  ===
+
L'option de validation rapide (Rapid Commit Option) indique l'utilisation d'un échange à deux messages pour l'allocation d'adresses ipv6.
+
 
+
Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.
+
 
+
Un serveur doit inclure cete option le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.
+
 
+
La structure de cette option est la suivante :
+
  0                  1                  2                  3
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_RAPID_COMMIT    |              0              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
 
+
=== Option classe d'utilisateur ===
+
L'option classe d'utilisateur (User Class Option)identifie un type ou une classe d'utilisateurs ou d'applications qu'ils représentent. La partie données de cette option contient plusieurs champs non interprétés (Opaque) par DHCPV6. Ces champs représentent la classe d'utilisateur à laquelle appartient le client.
+
 
+
Un serveur choisit les informations de configuration du client en fonction de la classe identifiée par l'option.
+
 
+
La structure de cette option est la suivante :
+
 
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|        OPTION_USER_CLASS    |        option-len            |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                        user-class-data                      .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
La structure de la partie données de cette option peut apparaître plusieurs fois. Elle est la suivante :
+
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :
|      user-class-len          |          opaque-data        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
  
=== Option de classe de constructeur ===
+
$ORIGIN nic.fr.
L'option de classe de constructeur (Vendor Class Option)identifie le constructeur du matériel qui supporte le client DHCPv6. Le numéro d'entreprise identifie le constructeur.
+
ns3 IN A 192.134.0.49
 +
    IN AAAA 2001:660:3006:1::1:1
  
La structure de cette option est la suivante :
+
Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion 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.
 +
<!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? -->
  
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
===Nommage inverse : enregistrement PTR===
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|      OPTION_VENDOR_CLASS      |        option-len            |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                      enterprise-number                      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                      vendor-class-data                      .
+
.                                                              .
+
.                                                              .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
  
Les paramètres définissant la classe du constructeur se suivent les uns les autres dans le champ de données de classe de constructeur. Chaque paramètre est codé en format LV. DHCPv6 n'interprète pas la valeur (opaque) de ces paramètres.
+
Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence).  
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
C'est-à-dire que, pour IPv4, 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. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.
|        vendor-class-len      |      opaque-data              |
+
<!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique -->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». 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 (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :
  
=== Option d'information spécifique d'un constructeur ===
+
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.6.6.0.1.0.0.2.ip6.arpa.
L'option d'information spécifique d'un constructeur (Vendor-specific Information Option) permet que les clients et serveurs DHCPv6 échangent des informations spécifiques d'un constructeur. Le numéro d'entreprise identifie le constructeur.  
+
  
La structure de cette option est la suivante :
+
'''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''
  
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir 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. Ceci facilite la gestion des données de résolution inverse.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|    OPTION_VENDOR_OPTS      |            option-len          |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|                      enterprise-number                      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                               .
+
.                         option-data                          .
+
.                                                               .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
  
La spécification des données échangées dépend du constructeur. Chacune de ces options de données est codée en format TLV. Le constructeur définit leur code. Plusieurs options de données peuvent se succéder dans le champ de données de l'optiond'information spécifique d'un constructeur.
+
Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone.  
 +
<!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.
 +
L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.
 +
Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.-->
  
La structure de l'option de donnée spécifique d'un constructeur est la suivante :
+
La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9).
 +
# L'IANA délègue (en termes 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.
 +
# 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.
 +
# Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement 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).
  
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
<center>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
[[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]
|           opt-code          |           option-len          |
+
</center>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                          option-data                          .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
  
=== Option d'identification d'interface ===
+
<!--La figure montre qu’une liste de 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 DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. -->
L'option d'identification d'interface (Interface-Id Option)identifie sur un relais, l'interface de réception du message d'un client.
+
  
Un relais qui reçoit un message incluant une option d'identification d'interface relaie le message reçu sur l'interface identifiée dans l'option.
+
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.  
  
Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option es spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cete information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.
+
Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> 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 <tt>2001:660:3006::/48</tt> à l'AFNIC et lui a délégué la zone DNS inverse correspondante :
  
La structure de cette option est la suivante :
+
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
 +
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.
  
    0                  1                  2                  3
+
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 :
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|    OPTION_INTERFACE_ID      |            option-len        |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
.                                                              .
+
.                        interface-id                          .
+
.                                                              .
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
=== Option de message de reconfiguration ===
+
L'option de message de reconfiguration (Reconfigure Message Option)présente dans un message de reconfiguration issue d'un serveur indique au client s'il doit répondre à l'aide d'un message RENEW ou INFORMATION-REQUEST.Cette option est spécifique du message de reconfiguration.
+
  
La structure de cette option est la suivante :
+
$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
 +
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.
 +
''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée <tt>ip6.arpa.</tt>, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''
  
  0                  1                  2                  3
+
==Découverte de la liste de serveurs DNS récursifs ==
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
* la première concerne l’ajout d’options dans les annonces de routeur ;
|      OPTION_RECONF_MSG      |          option-len          |
+
* la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
* la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.
|    msg-type  |
+
Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).  
+-+-+-+-+-+-+-+-+
+
=== option d'acceptation de reconfiguration ===
+
L'option d'acceptation de reconfiguration (Reconfigure Accept Option) annonce au serveur que le client accepte les messages de reconfiguration.
+
  
Un serveur utilise cette option pour dire au client s'il doit ou non accepter les messages de reconfiguration. L'absence de cette option indique le refux d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messsages de reconfiguration.
+
Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.
  
La structure de cette option est la suivante :
+
===Principe des trois propositions : RA, DHCPv6, anycast===
  
  0                  1                  2                  3
+
#'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration "sans état" (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour.
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
#'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 "à état" (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 "sans état" ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
#'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.
|      OPTION_RECONF_ACCEPT    |                0              |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
  
=== extension du protocole DHCPv6 : options spécifiques des relais ===
+
===Extension de l’autoconfiguration "sans état" pour le DNS ===
Dans certains cas les relais DHCPv6  connaissent des informations qui seraient utiles aux clients DHCPv6.  
+
Le RFC 4862 spécifie l'autoconfiguration IPv6 "sans état". Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recursive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL : ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''.  
  
Le protocole DHCPv6 est étendu (RFC 6422) pour que les relais puissent inclure une option RSSO : RELAY-SUPPLIED OPTIONS OPTION dans les messages RELAY-FORW adressés au serveur DHCPv6.
+
L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.
  
L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORW adressés au serveur DHCPv6 contient alors toutes les options correspondant à des paramètres que le relais souhaite porter à la connaissance du client. Cette possibilité n’est effective que pour des paramètres classés RSOO.
+
La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.
  
Le serveur DHCPv6 qui reçoit un message RELAY-FORW contenant une option RSSO enregistre les option classées RSOO fournies par le relais DHCPv6. Il peut ensuite transmettre ces informations aux clients en ajoutant les options de classe RSOO qu’il accepte de transmette au client.  
+
===Extension de la configuration "à état", DHCPv6===
 +
Le RFC 8415 spécifie le protocole d'autoconfiguration "à état", DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6.
 +
La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.
  
Notez que le relais transmet ces paramètres spécifiques de relais au serveur. Le serveur décide ensuite de transmettre tout ou partie de ces informations au client, éventuellement en fonction de la politique définie par l'administrateur du réseau.
+
===Utilisation d’adresses anycast réservées===
 +
Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau.  
  
Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un client.  
+
Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services "sans état" et "avec état", notamment lorsque plusieurs serveurs sont susceptibles de répondre.
  
La structure de cette option est la suivante :
+
== Mises en œuvre d'un serveur de noms ==
 +
La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.
  
0                  1                  2                  3
+
== Références bibliographiques ==
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+
<references />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|          OPTION_RSOO (66)    |          option-length      |
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
| options    ...
+
+-+-+-+-+-+-+-+-+-+-+-+
+
  
Pour en savoir plus lisez le RFC 6422.
+
* La terminologie du service DNS : Analyse par S. Bortzmeyer :
 +
** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]
 +
** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]
 +
** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]
 +
** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]
 +
** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]
  
== Annexe 2. Codes d’état du protocole DHCPv6 ==
+
== Pour aller plus loin==
Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 3315.
+
RFC et leur analyse par S. Bortzmeyer :
Name        Code Description
+
* RFC 608 Host Names On-line
----------  ---- -----------
+
* RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]
Success        0 Success.
+
* RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]
UnspecFail      1 Failure, reason unspecified; this
+
* RFC 1546 Host Anycasting Service
                  status code is sent by either a client
+
* RFC 1912 Common DNS Operational and Configuration Errors
                  or a server to indicate a failure
+
* RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]
                  not explicitly specified in this
+
* RFC 3596 DNS Extensions to Support IP Version 6
                  document.
+
* RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]
NoAddrsAvail    2 Server has no addresses available to assign to
+
* RFC 3901 DNS IPv6 Transport Operational Guidelines
                  the IA(s).
+
* RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]
NoBinding      3 Client record (binding) unavailable.
+
* RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches
NotOnLink      4 The prefix for the address is not appropriate for
+
* RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]
                  the link to which the client is attached.
+
* RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]
UseMulticast    5 Sent by a server to a client to force the
+
* RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]
                  client to send messages to the server.
+
* RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]
                  using the All_DHCPV6_Relay_Agents_and_Servers
+
* RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]
                  address.
+
* RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 +
* RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
 +
* RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]

Latest revision as of 10:29, 16 January 2024


Activité 33 : Faire correspondre adresse et nom de domaine

Introduction

Cette activité introduit le système de nommage communément appelé DNS (Domain Name System). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS[1].

Concepts de base du DNS

Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : Fully Qualified Domain Name) et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (Mail eXchanger, MX) ou encore celles relatives aux serveurs de noms (Name Servers, NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP.

Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, www.tpt.example.com ou ftp.tpt.example.com représentent respectivement les noms des serveurs Web et FTP de la société tpt.example.com.

Une application qui s’exécute sur un équipement A, et qui souhaite 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 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. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées.

Nommage « à plat »

Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier hosts.txt (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier /etc/hosts pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.

Caractéristiques du système de noms de domaine

Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (Request For Comments). Il est notamment célèbre pour être l'auteur de cette phrase : «Be liberal in what you accept, and conservative in what you send».

Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes "nom-adresse" et des correspondances inverses "adresse-nom". Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage 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 infrastructure critique pour 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 système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). 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 à chacune de ses feuilles. 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 de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. 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 ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.

Arbres informatiques

Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.

Figure 1 : Arbre de nommage.

Les nœuds du premier niveau (les fils de la racine) sont couramment dénommés Top Level Domain (TLD). Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé "arpa" sont dédiés à la résolution inverse : in-addr pour IPv4 et ip6 pour IPv6.

  • Réparti. Nul 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 de 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.
  • 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 géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois 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. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires.
    • Équilibrage de charge. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le 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.
  • Extensible. La structure d'arbre est extensible (scalable) (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter 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.

Extensibilité des arbres

Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux

Figure 2 : Extension de l'arbre de nommage.

L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des "sous-arbres". Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.

Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.

Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.

Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.

Principe de fonctionnement du service DNS

Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (stub resolver) 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). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ( Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP). Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque (selon le mécanisme des appels système).

Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.

Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.

Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.


On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier db.root. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. 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. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN tpt.example.com. à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD .com. et enfin le serveur en charge du domaine example.com.. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.

Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.

Les serveurs de noms

L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.

Serveurs de noms primaires et secondaires

Gestion des données de zone

À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.

Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.

Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).

Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.
Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.

Redémarrage et réinitialisation d'un serveur DNS

Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (Random Access Memory). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM.

Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation).

Synchronisation par notification : lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.

Synchronisation par interrogation : lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.


Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.


Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).

Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.

Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.

Serveur DNS récursif (caching name server)

Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse (cf. schéma de principe de la résolution de la figure 4). Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS "cache". Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.

Relais DNS (forwarder)

Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit "relais DNS" (forwarder). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse.

Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite démilitarisée (DMZ) de "l'autre coté" du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.

Serveurs DNS à rôles multiples

Un serveur DNS BIND (BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS) peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients.

Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.

Spécifications du service de nommage

Spécifications du résolveur

Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé stub resolver, interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service 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.

Singularité du service DNS

Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.

Pour les machines Unix, par exemple, le fichier de configuration du client DNS, /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 serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé "Découverte de la liste des serveurs DNS récursifs".

Spécifications des ressources IPv6

Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées Ressource Record ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX (Mail eXchanger) pour une correspondance entre un domaine et son ou ses relais de messagerie.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ip6.arpa.

  • Le RR de type AAAA (prononcé « quad A ») enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.
  • 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, pour IPv6, la notion de quartet (nibble). Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.

Nommage direct : enregistrement AAAA

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. (De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR 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 multi-domiciliée ou routeur, par exemple)).

Une requête DNS de type AAAA concernant un FQDN (Fully Qualified Domain Name) renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre Publication des enregistrements AAAA dans le DNS. Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire). 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:660:3006:1::1:1

Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, dual-stack), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ns3.nic.fr sont publiées dans le fichier de zone nic.fr comme suit :

$ORIGIN nic.fr.
ns3 IN A 192.134.0.49
    IN AAAA 2001:660:3006:1::1:1

Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion 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.

Nommage inverse : enregistrement PTR

Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence).

C'est-à-dire que, pour IPv4, 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. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse. Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «.». 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 (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse 2001:660:3006:1::1:1 (adresse de ns3.nic.fr) donne 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.6.6.0.1.0.0.2.ip6.arpa.

Note : les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.

L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR (PoinTeR) correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ns3.nic.fr. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir 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. Ceci facilite la gestion des données de résolution inverse.

Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone.

La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9).

  1. L'IANA délègue (en termes 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.
  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.
  3. Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement 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).
Figure 9 : Délégation du nommage inverse.


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.

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 :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
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.

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.
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.

Note : astuce : la clause $ORIGIN (macro) en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée ip6.arpa., on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.

Découverte de la liste de serveurs DNS récursifs

Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :

  • la première concerne l’ajout d’options dans les annonces de routeur ;
  • la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;
  • la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.

Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339).

Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

Principe des trois propositions : RA, DHCPv6, anycast

  1. RA : le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration "sans état" (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour.
  2. DHCPv6 : le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 "à état" (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 "sans état" ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.
  3. Anycast : mécanisme à base d'adresses anycast réservées (Well-known anycast addresses). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.

Extension de l’autoconfiguration "sans état" pour le DNS

Le RFC 4862 spécifie l'autoconfiguration IPv6 "sans état". Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : Recursive DNS Server) et une option pour définir la liste des noms de domaines recherchés (DNSSL : DNS Search List). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier resolv.conf.

L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.

La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.

Extension de la configuration "à état", DHCPv6

Le RFC 8415 spécifie le protocole d'autoconfiguration "à état", DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.

Utilisation d’adresses anycast réservées

Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau.

Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services "sans état" et "avec état", notamment lorsque plusieurs serveurs sont susceptibles de répondre.

Mises en œuvre d'un serveur de noms

La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.

Références bibliographiques

  1. Zitrax Livre sur les principes du DNS et les éléments de configuration de bind

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

Personal tools