Sequence 3
Sequence 3
Sequence 3
Séquence 3
Attribution - Partage dans les Mêmes Conditions 4.0 International (CC BY-SA 4.0)
Avertissement Ce résumé n'indique que certaines des dispositions clé de la licence. Ce n'est pas une licence, il
n'a pas de valeur juridique. Vous devez lire attentivement tous les termes et conditions de la licence avant d'utiliser
le matériel licencié.
Creative Commons n'est pas un cabinet d'avocat et n'est pas un service de conseil juridique. Distribuer, afficher et
faire un lien vers le résumé ou la licence ne constitue pas une relation client-avocat ou tout autre type de relation
entre vous et Creative Commons.
http://creativecommons.org/licenses/by-sa/4.0/legalcode
• Partager — copier, distribuer et communiquer le matériel par tous moyens et sous tous formats
L'Offrant ne peut retirer les autorisations concédées par la licence tant que vous appliquez les termes de cette
licence.
Partage dans les Mêmes Conditions — Dans le cas où vous effectuez un remix, que vous transformez,
ou créez à partir du matériel composant l'Oeuvre originale, vous devez diffuser l'Oeuvre modifiée dans les même
conditions, c'est à dire avec la même licence avec laquelle l'Oeuvre originale a été diffusée.
No additional restrictions — Vous n'êtes pas autorisé à appliquer des conditions légales ou des mesures
techniques qui restreindraient légalement autrui à utiliser l'Oeuvre dans les conditions décrites par la licence.
Notes: Vous n'êtes pas dans l'obligation de respecter la licence pour les éléments ou matériel appartenant au
domaine public ou dans le cas où l'utilisation que vous souhaitez faire est couverte par une exception.
Aucune garantie n'est donnée. Il se peut que la licence ne vous donne pas toutes les permissions nécessaires
pour votre utilisation. Par exemple, certains droits comme les droits moraux, le droit des données personnelles
et le droit à l'image sont susceptibles de limiter votre utilisation.
Bruno Stévant
Bruno STEVANT est enseignant chercheur à l'IMT Atlantique.
Il intervient dans l’enseignement et sur les projets de
recherche autour d’IPv6 depuis plus de 10 ans. Il est
secrétaire et responsable des activités de formation de
l’association G6, association pour la promotion et le déploiement d'IPv6 en
France.
Jacques Landru
Enseignant chercheur au département Informatique et
Réseaux à l'IMT Lille Douai, Jacques est responsable de l'UV
de spécialisation ARES (Architecture des RESeaux) à la fois
dans le mode traditionnel présentiel que dans sa forme à
distance dans le cadre du cursus diplômant TutTelNet.
Jean-Pierre Rioual
Ingénieur Conseil Réseaux – EURÊKOM. Fort de 30 années
d'expérience dans le domaine des réseaux, il intervient auprès
des entreprises pour des missions d'expertise sur leurs
réseaux de transmission de données (intégration, mesures,
optimisation, administration), conçoit et anime des actions de formation "réseaux".
Véronique Vèque
Véronique Vèque est Professeur des Universités à l’Université
Paris-Saclay. Elle enseigne les réseaux depuis plus de 20 ans
en Master Réseaux et Télécoms. Elle poursuit ses recherches
au sein du L2S (Laboratoire des Signaux et Systèmes) où elle
est responsable de l’équipe Réseaux, optimisation et codage. Elle est directrice-
adjointe de l’école doctorale STIC de l’Université Paris-Saclay.
Pascal Anelli
Pascal ANELLI est enseignant-chercheur à l'Université de la
Réunion. Il enseigne les réseaux depuis plus 20 ans. Il est
membre du G6 depuis sa création. A ce titre, il est un des
contributeurs du livre IPv6. En 1996, il a participé au
développement d'une version de la pile IPv6 pour Linux.
Joël Grouffaud
Joël GROUFFAUD est professeur agrégé de mathématiques.
Il est chef du département Réseaux et Télécommunications de
l’IUT de la Réunion, une composante de l’université de La
Réunion. Au sein du département, il enseigne les réseaux et
IPv6. Il anime l’académie Cisco (formations CCNA) de La
Réunion.
Remerciements à :
• Vincent Lerouvillois, pour son travail de relecture attentive ;
• Bruno Di Gennaro (Association G6) ;
• Bruno Joachim (Association G6) pour sa contribution à l'activité « Contrôler
la configuration réseau par DHCPv6 » ;
• Richard Lorion (Université de la Réunion) pour sa contribution à l’activité
« Etablir la connectivité IPv6 tunnels pour IPv6 ».
Les auteurs....................................................................................................................................5
Quels sont les mécanismes nécessaires pour faire fonctionner un réseau avec IPv6 ?...13
Plan de la séquence.................................................................................................................13
Conclusion..................................................................................................................................85
Exemple d’interrogation d’un serveur DNS avec la commande host : résolution inverse
.......................................................................................................................................113
Recommandations opérationnelles pour l'intégration d'IPv6.................................................113
Deux impossibilités d’accéder au service de nommage et leurs remèdes........................114
Premier scénario : client IPv4 et serveur IPv6...............................................................114
Second scénario : client IPv6 et serveur IPv4...............................................................114
Taille limitée des messages DNS en UDP, extension EDNS.0..........................................115
Glue IPv6............................................................................................................................116
Publication des enregistrements AAAA dans le DNS........................................................116
Pour aller plus loin : mises à jour dynamiques du DNS.....................................................117
Conclusion..............................................................................................................................118
Plan de la séquence
La première activité va présenter le protocole ICMPv6, les formats des différents messages et
les cas où ces messages peuvent apparaître dans le réseau. La seconde activité s'attachera à
décrire la configuration automatique d'un nouveau nœud au sein du réseau local. La
troisième activité abordera la configuration automatique "avec état". Enfin, dans la dernière
activité, vous étudierez le fonctionnement du système de nommage. Ce système est essentiel
pour utiliser des noms à la place des adresses IP. Les machines et services Internet désignés
par des noms présentent l'avantage d'être facilement mémorisables par les utilisateurs.
Introduction
Le bon fonctionnement de la couche réseau est supervisé par le protocole ICMPv6 (Internet
Message Control Protocol) [RFC 4443]. Tout comme ICMP pour IPv4, ICMPv6 s'appuie sur
IPv6 pour réaliser ces fonctions. La famille des protocoles ICMP donne les informations sur
l'état de marche du réseau. Elle rapporte également les erreurs quand un paquet ne peut être
traité correctement. On distingue 3 fonctions propres à ICMP :
• le signalement d'erreur en cours d'acheminement d'un paquet ;
• le test d'accessibilité d'un nœud ;
• la configuration automatique des équipements.
Terminologie
Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement
terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se
qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.
À la différence d'ICMP pour IPv4, qui comporte également ces trois fonctions, ICMPv6 intègre
les fonctions de gestion des groupes de multicast (Multicast Listener Discovery (MLD)) et de
résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des
protocoles annexes (la gestion des groupes était du ressort de IGMP (Internet Group
Management Protocol), et la résolution d'adresse, du protocole ARP (Address Resolution
Protocol). La résolution d'adresse en IPv6 s'effectue par la procédure de découverte des
voisins (Neighbor Discovery Protocol(NDP)). La notion de voisinage est définie par la
connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le
même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au
moins un routeur. ICMPv6 comporte aussi des fonctions pour la mobilité IP. Il en ressort
qu'ICMPv6 est bien plus complet que son prédécesseur. Non seulement ICMPv6 rapporte les
erreurs, mais pour les mécanismes d'autoconfiguration ou de découverte du voisinage, il est un
élément indispensable dans le service de connectivité offert par la couche de réseau.
d'informations et un autre pour les messages d'erreurs. Les groupes sont identifiés par le
bit de poids fort de ce champ. Les messages d'erreurs ont ce bit à zéro et donc, le champ
Type prendra, pour ces messages, une valeur comprise entre 0 et 127. Les messages
d'informations sont identifiés par un champ Type dont la valeur est comprise entre 128 et
255.
2. Le champ Code s'interprète dans le contexte du type de message. Il est utilisé pour
ajouter une granularité plus fine au type.
3. Le champ Checksum sert à vérifier l'intégrité du message ICMP. Il porte aussi bien sur
l'en-tête du message que sur sa charge utile.
1 Destination inaccessible :
interdite.
3 Délai expiré :
4 Erreur de paramètre :
Message d'information
Rapport d'erreur
ICMPv6 permet de signaler, à l'émetteur d'un paquet, un problème dans son acheminement ou
dans sa réception, par des messages de rapport d'erreur. Lorsqu'une machine émet un paquet,
si une erreur est détectée par le destinataire ou par tout routeur intermédiaire le long du chemin
vers le destinataire, alors l'élément qui détecte l'erreur renvoie à l'émetteur un rapport sous la
forme d'un message ICMPv6. Le type du message et son code définissent précisément l'erreur
détectée. L'extrait, jusqu'à concurrence de 1280 octets du paquet en défaut, est incluse pour
permettre l'analyse de l'erreur. L'exemple ci-dessous illustre un message ICMP Paquet trop
grand, généré par un routeur intermédiaire dès qu'un datagramme ne peut être retransmis en
raison de la limitation de la MTU sur son interface de sortie.
Différentes erreurs peuvent être signalées par ICMPv6. Les cas les plus courants sont :
• destination inaccessible (type 1), la raison est précisée par le champ Code ;
• paquet trop grand (type 2) ;
• délai expiré (type 3) ;
• erreur de paramètre (type 4).
Nota : une description de ces messages ICMPv6 est disponible dans le document annexe à
cette activité : MOOC:Annexe_Compagnon_Act31.
Découverte de voisins
137 Redirection
141 Sollicitation
142 Annonce
Sollicitation de chemin de
148
certification
Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de
souligner que le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255. Cette
valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du
lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela
signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les
datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.
Figure 10 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.
Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande ping6. La
commande entrée sur Uma est la suivante :
uma# ping6 ganesha
trying to get source for ganesha
source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
PING ganesha (2001:db8:12:3::3): 56 data bytes
64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms
Commande ping6
La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro
l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une
option -6 qui rend cette commande équivalente à la commande ping6.
Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître
l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le
destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud
destinataire de la transmission comme le routeur du lien (Next hop). L'émetteur utilise le
protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il
commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le
montre la trace 3.
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)
ICMPv6
Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f
Cible : 2001:db8:12:3::3 (ganesha)
Option :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-
6d
0000: 6f 00 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03
0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00
0020: 00 00 00 01 ff 00 00 03|87|00|4d 7f|00 00 00 00|
0030: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|
0040: 01|01|08 00 20 0a aa 6d
Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités
associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ Cible une de ses
adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La
trace 4 montre la réponse émise.
Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
Version : 6 Classe : 0xf0 Label : 000000
Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)
ICMPv6
Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb
Bits (0x7) R = 1, S = 1, O = 1
Cible : 2001:db8:12:3::3 (ganesha)
Option :
Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
La réception du message "Annonce voisin" (NA) par Ganesha apporte la confirmation que son
voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ
cible du message d'annonce de voisin.
IPv6
Version : 6 Classe : 0x00 Label : 000000
Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0xff)
Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
ICMPv6
Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f
Bits (0x4) R = 0, S = 1, O = 0
Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429,
il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin
d'utiliser l'adresse de manière anticipée. Dans ce RFC, on trouve, en Annexe A, une étude de
la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus
probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste
malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable
pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses
n'enlèverait pas l'erreur.
Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à
la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications.
Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le
champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste
à envoyer un message "sollicitation d'un voisin" avec, dans le champ adresse de la
cible, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des
voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de
source l'adresse indéterminée. Trois cas se présentent :
1. Un message "Annonce d'un voisin" est reçu : l'adresse provisoire est utilisée comme
adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être
retenue.
2. Un message "Sollicitation d'un voisin" est reçu dans le cadre d'une procédure DAD :
l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse
provisoire ne peut être utilisée par aucun des nœuds.
3. Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est
unique. Elle passe de l'état "provisoire" à celui de "valide" et elle est assignée à
l'interface.
La trace affichée par la commande tcpdump ci-dessous illustre le premier cas. Un hôte active
son interface réseau, et après avoir constitué une adresse unicast par auto-configuration,
effectue une DAD (nous verrons le détail de la construction de l'adresse dans la prochaine
activité). Comme l'adresse provisoire n'est pas unique, un message NA est reçu pour signaler
que cette adresse est une adresse valide d'un autre nœud sur le lien.
1 IP6 :: > ff02::1:ff02:202: ICMP6, neighbor solicitation, who has
2001:db8:b:2:fd:c8ff:fe02:202
2 IP6 2001:db8:b:2:fd:c8ff:fe02:202 > ff02::1: ICMP6, neighbor
advertisement, tgt is 2001:db8:b:2:fd:c8ff:fe02:202
Conclusion
Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en
effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts
qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.
A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont
notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non livraison d'un paquet, les
informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la
communication si besoin est. A l'échelle du lien, c'est à travers le protocole ICMPv6 que les
nœuds se découvrent entre eux, vérifient l'unicité de leurs adresses et gèrent les abonnements
aux groupes multicast.
Références bibliographiques
1. ↑ IANA. Internet Control Message Protocol version 6 (ICMPv6) Parameters
Principe de l'auto-configuration
La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud
connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du
même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique
(ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est
de réduire au maximum l'intervention humaine dans ce processus pour :
• que l'utilisateur possède une connectivité opérationnelle dès le branchement de
l'interface réseau de son terminal ;
• que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce
dernier qui se chargera de propager la configuration aux hôtes.
Route par défaut
La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle
dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui
connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que
l'hôte. Dans un réseau routier, la route par défaut correspond au panneau "Toutes Directions".
L'auto-configuration vise à fournir les informations pour que l'interface de communication au
réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants :
• les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode
pour l'obtenir ;
• la longueur du préfixe IP du réseau ;
• l'adresse du routeur local à utiliser pour la route par défaut ;
• le serveur de noms à utiliser.
L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes
récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à
leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors
effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP.
L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans
l'infrastructure, comme les routeurs, étant des équipements "gérés", ils ne sont pas censés
utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.
Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'.
Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours
aux informations d'un serveur comme c'est le cas avec DHCP.
L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes :
• la toute première étape consiste à créer l'adresse "lien-local". Une fois l'unicité de cette
adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres
nœuds du lien (ses voisins) ;
• le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la
politique de configuration de l'adresse IP. Ces informations sont transmises par le
routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par
le message d'annonce de routeurs, à savoir :
• l'auto-configuration "sans état" (IPv6 Stateless Address Autoconfiguration
(SLAAC)) [RFC 4862],
• ou l'auto-configuration "avec état" (par DHCPv6) [RFC 3315] ;
• les informations transmises par le routeur permettent de plus, au nœud, de configurer sa
table de routage.
• enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres
informations nécessaires à la configuration dont, notamment, le serveur de noms.
En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par
la méthode d'auto-configuration "avec état". Si la tentative échoue, c'est terminé. Les
communications se feront uniquement sur le lien avec l'adresse "lien-local". Le nœud n'a pas
d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de
son lien d'attachement.
exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont
même qualifiés de RAcailles[1].
bits.
Interprétation du bit L
L'interprétation du bit L à 0 (signifiant implicitement "off-link") a fait l'objet de précisions
complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ).
Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered
Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between
Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la
procédure de découverte du voisinage dans des situations particulières, notamment lorsque la
liste des routeurs par défaut est vide.
Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des
réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles
ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un
nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des
téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire
(un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du
voisinage. L'état "off-link" d'une adresse est alors significatif.
Au passage, la précaution de forcer le champ "Hop-limit" à la valeur maximale à 255 pour les
paquets de découverte de voisins, protège des nœuds hors lien qui émettraient
accidentellement, ou par malice, des messages ND.
L'introduction, dans les infrastructures de type "cloud" de nouveaux protocoles, tels que
VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données
(data centers) distants ajoutent de nouvelles situations où le mode hors lien peut être
significatif.
Comme pour la création de l'adresse "lien-local", l'adresse IP unicast routable est obtenue en
concaténant le préfixe avec l'identifiant de l'interface. L"adresse IP unicast routable est une
adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une
adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage
global (GUA). Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs,
et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le
nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC
4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 4941]. Profitant de la
souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.
Les valeurs de durée préférable et de durée de validité contrôlent le cycle de vie des
adresses créées. Une fois la durée préférable écoulée, l'adresse concernée passera de
l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir
de la réception du message d'annonce d'un routeur. Et, lorsque le temps, indiqué par la durée
de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des
valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds
d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la
renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à
un autre.
Une des propositions s'appuie sur des adresses anycast bien connues (Well-known anycast
addresses). L'idée est que les demandes au service DNS seraient émises par les clients vers
une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche.
Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.
La première proposition mise en œuvre repose sur le protocole DHCP et l'option DHCPv6 DNS
Recursive Name Server spécifiée dans le RFC 3646. Un serveur DHCPv6 dit "sans état" [RFC
3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents
paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression... Depuis, le protocole
DHCPv6 pour serveur "avec état" a été développé [RFC 3315]. En plus des informations de
configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine
activité de ce cours.
La seconde proposition, appelée ND RDNSS (Neighbor Discovery Recursive DNS Server), a
été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND
RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS.
La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes
d'exploitation[2].
préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui
assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de
l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique
et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS
extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs
NAT64 (cf activité 44).
En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également
synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du
préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être
découverts de manière automatique selon une des deux méthodes suivantes :
• déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6
Prefix Used for IPv6 Address Synthesis) ;
• déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option
PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements).
Nota : Au moment de la rédaction de ce document compagnon, il ne semble pas que l'option
PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les
récepteurs. Par contre Wireshark sait déjà le décoder.
La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité
"Utilisation des adresses sur une interface réseau" de la séquence 1. En résumé, cela consiste
à inverser la valeur du 7e bit de l'octet de poids fort de l'adresse physique et d'ajouter au
milieu de l'adresse MAC, soit après le 3e octet, la valeur OxFFFE.
0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00
0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00
0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d
Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme
d'auto-configuration échoue et une intervention humaine est nécessaire. Si aucune réponse
n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son
adresse "lien-local" comme unique. L'adresse perd son état provisoire et devient valide.
Cette première étape terminée, la station possède donc une adresse "lien-local" pour
communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher
maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des
nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination
de tous les routeurs du lien en utilisant l'adresse multicast correspondante : ff02::2 comme
Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.
Le message ainsi émis est présenté ci-dessous sous sa forme capturée :
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:0:0:0:2 Type : 0x86dd
IPv6
Version : 6 Priorité : 0xf0 Label: 000000
Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 255 (0x0ff)
Source : fe80::a00:20ff:fe0a:aa6d (lien-local)
Desti. : ff02::2 (multicast, tous les routeurs du lien)
ICMPv6
Type : 133 (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e
Option :
Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-
6d
0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00
0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|
0030: 01 01 08 00 20 0a aa 6d
Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y
trouve les instructions d'auto-configuration par les bits M et O, ainsi que les informations sur le
ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.
0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00
0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70
0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|
0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00
0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00
De la même façon que l'unicité de l'adresse "lien-local" a été vérifiée, la station utilise le
mécanisme DAD pour vérifier l'unicité de l'adresse "unicast globale" construite à partir du
préfixe communiqué. Cette procédure est schématisée par la figure 9.
Conclusion
L'auto-configuration "sans état" des paramètres réseau IPv6 permet une connectivité
fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite
aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la
configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui
devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont
ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se
configurer.
L'auto-configuration "sans état" a d'autres avantages par rapport à des méthodes manuelles ou
reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent
de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre
préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les
instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être
facilité par la configuration automatique.
Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour
certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par
exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être
utilisé à cette fin.
Références bibliographiques
1. ↑ Bortzmeyer, S. (2013). Article. Rogue IPv6 Router Advertisement Problem Statement
2. ↑ APNIC. Comparison of IPv6 support in operating systems
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].
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.
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.
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é.
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
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
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.
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.
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
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 :
[ttl] IN AAAA
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:3006: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:db8: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.
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).
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.
(RDNSS : Recrusive 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é.
Références bibliographiques
1. ↑ Zitrax Livre sur les principes du DNS et les éléments de configuration de bind
• La terminologie du service DNS : Analyse par S. Bortzmeyer :
• RFC8499 : DNS Terminology
• Résolveur DNS : Définition
• Serveur DNS faisant autorité : Définition
• Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?
Introduction
L'autoconfiguration "à état" utilise un serveur pour allouer des adresses IPv6 ou des paramètres
de configuration à des nœuds IPv6. Elle réduit les efforts de configuration des nœuds IPv6, tout
comme l'autoconfiguration "sans état". Elle offre, à la différence de l'autoconfiguration "sans
état", une information de configuration plus riche et un meilleur contrôle de l'affectation des
paramètres de configuration. Elle permet en outre la reconfiguration éventuelle des
équipements du réseau.
Les deux techniques d'auto-configuration, "avec état" et "sans état", ne sont pas exclusives et
peuvent coexister dans un même environnement. Un nœud peut, par exemple, obtenir son
adresse "unicast globale" par auto-configuration "sans état" et obtenir les informations relatives
aux serveurs de noms (DNS) par l'autoconfiguration "avec état".
L'autoconfiguration "avec état" permet :
• d'assigner des adresses IPv6 stables et prédictibles à la demande et de manière
contrôlée ;
• de provisionner au préalable les adresses à assigner aux nœuds ;
• d'automatiser le mécanisme d'assignement ;
• de centraliser les configurations.
Tout le mécanisme d'autoconfiguration "avec état" est bâti sur le modèle client-serveur. Il utilise
le protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6).
communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien
(au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les
mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les
serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux
clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives
aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux
types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre
relais, soit entre relais et serveurs.
Communication en DHCPv6
DHCPv6 utilise le protocole de transport UDP. Les messages UDP sont encapsulés dans des
datagrammes IPv6. Les numéros de ports d'écoute utilisés sont 546 pour le client et 547 pour
les serveurs ou les relais.
Lorsque le client et le serveur sont sur le même lien, le serveur reçoit la requête du client sur
son port 547. Lorsque le client n’est pas sur le même lien que le serveur, un relais reçoit la
demande du client sur son port 547. Le relais réexpédie ensuite ce message vers le port 547 du
relais suivant ou du serveur.
Le serveur DHCPv6 envoie ses réponses depuis son port 547. Il les envoie vers le port 546 du
client si la remise directe est possible. Sinon, le serveur envoie sa réponse au premier relais du
chemin de retour, sur le port 547.
En fonction des indications du serveur DHCPv6, les communications peuvent, au niveau IPv6,
se faire en point à point ou en multidiffusion pour la découverte des serveurs DHCPv6. IPv6
s'appuie ensuite sur les fonctions de diffusion générale ou sélective du réseau physique sous-
jacent pour assurer le transport effectif des messages vers leur destination. Lorsque le réseau
n'est pas diffusant, il fait par exemple appel à un serveur de diffusion.
du client. Ils utilisent pour cela des options spécifiques des relais. Notez que ni les relais,
ni le serveur ne modifient les messages du client. Les relais se contentent de les
encapsuler dans une option de message de relais avant de les relayer vers le serveur.
• Les interrogateurs (requestors) [RFC 5007] sont des entités spécifiques. Les
administrateurs les utilisent pour demander à un serveur DHCPv6 des informations
relatives aux clients. Un administrateur peut ainsi obtenir des informations relatives au
bail d’un client ou à la machine qui utilise une adresse à un instant donné, ou encore
obtenir les adresses allouées à un client donné. Nous ne détaillerons pas ici leur
utilisation.
Figure 1 : Dialogue entre client et serveur DHCPv6 présents sur le même lien physique.
Le chemin inverse n’est par conséquent pas difficile à construire. Le protocole DHCPv6 peut
ainsi faire parvenir la réponse du serveur au client.
Figure 2 : Dialogue entre client et serveur DHCPv6 non présents sur le même lien physique.
Après la phase d'acquisition de l'adresse IPv6, le client DHCPv6 vérifie que l'adresse IPv6
allouée n'est pas déjà en service (DAD : détection d'adresse dupliquée). Il configure alors ses
interfaces de réseau, et l'utilisateur qui travaille sur le client DHCPv6 peut accéder au réseau.
Le processus DHCPv6 client devient alors inactif jusqu'à ce que l'utilisateur qui travaille sur le
client DHCPv6 ferme sa session et arrête le client. Il se réactive alors pour libérer ( release)
l'adresse IPv6 allouée.
Figure 3 : Libération d'une adresse IPv6 obtenue directement d'un serveur DHCPv6.
La figure 4 ci-dessous présente la libération de l'adresse IPv6 en présence d'un relais :
Figure 4 : Libération d'une adresse IPv6 obtenue via un relais DHCPv6.
client, ce qui n’est pas toujours le cas. Or, la DAD n’est possible que sur un lien auquel on est
connecté.
Un serveur utilise le message RECONFIGURE (champ Type = 10) pour signaler au client qu'il
a de nouveaux paramètres de configuration du réseau ou les a actualisés. Ce message précise
en particulier si le client doit utiliser le message RENEW ou REBIND.
Un client utilise le message INFORMATION-REQUEST (champ Type = 11) pour demander au
serveur des paramètres de configuration du réseau, sans demander d’adresse.
Figure 5 : Format des messages échangés entre clients et serveurs DHCPv6.
Type-msg : le champ type de message identifie la nature du message DHCPv6. Il est codé
sur un octet.
Id-transaction : l'identificateur de transaction identifie un échange (question/réponse). Il est
spécifique aux messages participant à une transaction, et est globalement unique. Il permet
d'associer les réponses aux requêtes correspondantes. En effet, la couche transport UDP ne
garantit pas le séquencement des réponses lorsque plusieurs requêtes successives ont été
émises à destination d'un serveur. Il est codé sur 3 octets.
Option list : la liste des options du message est de taille variable. Elle correspond à une
succession d'options rangées séquentiellement, selon la sémantique du message, et
uniquement alignées sur des frontières d'octets. Il n'y a pas de bourrage entre deux options
consécutives. Elles transportent soit les adresses IPv6, soit les paramètres de configuration du
réseau (hors adresse IPv6) nécessaires au fonctionnement du réseau.
Pour en savoir plus sur les options, reportez-vous à l’annexe 1 Options du protocole DHCPv6
de cette activité.
Figure 6 : Format des messages échangés entre relais et serveurs DHVPv6.
Les messages utilisés pour la communication entre serveur et relais sont différents des
messages utilisés pour la communication entre client et serveur. Un message RELAY-
FORWARD transite d'un relais vers un serveur. Un message RELAY-REPLY transite du serveur
vers le client.
Type-msg : le type du message identifie le type du message DHCPv6.
Hop-count : le nombre de sauts identifie soit le nombre de relais déjà traversés pour atteindre
le serveur, soit le nombre de relais restant à traverser pour atteindre le client.
Link-address : l'adresse de lien est une adresse unicast (globale ou locale) qui sera utilisée
par le serveur pour identifier le lien sur lequel est localisé le client. C'est l'adresse unicast
(globale ou locale) du relais du coté du client.
Peer-address : l'adresse du pair est l'adresse du client ou du relais depuis laquelle le
message à relayer a été reçu. Elle est extraite de l'adresse source du paquet du message reçu.
Elle permet d'identifier l'interface du relais derrière laquelle se trouve le client. Elle sera utilisée
Association d'identités
Une association d’identités IA (Identity Association) permet qu’un serveur ou un client identifie,
groupe ou gère un ensemble d’adresses IPv6 associées. Chaque association se compose d’un
identificateur d’association et des informations de configuration associées. Ces informations
sont enregistrées dans des options de l'association.
Un client associe au moins une association d’identités, IA, à chacune des interfaces de réseau
pour laquelle il requiert une adresse IPv6.
Cette IA reste affectée en permanence à l'interface. Elle simplifie le format des messages
DHCPv6, la gestion de la durée de vie des adresses IPv6 ou encore la renumérotation du
réseau IPv6.
OPTION_CLIENT
1 Identification du client
ID
OPTION_SERVER
2 Identification du serveur
ID
OPTION_ELAPSE Temps écoulé depuis le démarrage d'un échange pour la machine qui
8
D_TIME tente d’achever sa configuration.
OPTION_STATUS
13 Indique le statut du message DHCPv6 qui transporte cette option.
_CODE
OPTION_VENDOR
16 Identifie le constructeur du matériel utilisé par le client.
_CLASS
OPTION_INTERF
18 Identifie l’interface de réception du message du client DHCPv6.
ACE_ID
Renumérotation passive
Dans la renumérotation passive, chaque machine du réseau dispose de deux adresses IPv6 :
une ancienne et une nouvelle. L'ancienne adresse est utilisée par les communications en cours.
Ces communications sont préservées aussi longtemps que nécessaire (RENEW). Par contre,
les nouvelles communications sont établies à l'aide de la nouvelle adresse. La renumérotation
est terminée lorsque la dernière machine du réseau cesse d'utiliser son ancienne adresse.
Renumérotation active
Dans la renumérotation active, chaque machine, comme dans le cas précédent, dispose d'une
ancienne adresse et d'une nouvelle.
Le serveur DHCPv6 force les clients à cesser d'utiliser leur ancienne adresse à une date
donnée. Le serveur réduit la durée de vie des anciennes adresses en fonction de la date
d'échéance cible.
Lorsque la date d'échéance arrive, aucune utilisation d'ancienne adresse n'est possible. Toutes
les communications utilisant les anciennes adresses sont coupées. Elles sont, en cas de
besoin, rétablies en utilisant les nouvelles adresses.
Ici encore, la délégation de préfixe à états peut faciliter les choses en permettant que les
machines autoconfigurent leurs nouvelles adresses.
Notez que l'utilisation du préfixe alloué sur le routeur demandeur est impossible sur le lien
donnant accès au routeur délégataire. Ceci empêche par conséquent l'agrégation des routes
d'accès au routeur demandeur et d'accès au réseau qu'il dessert.
Deux autres options [RFC 6603], permettent d'exclure un seul préfixe pour l'affecter au lien qui,
sur le routeur demandeur, donne accès au routeur délégataire.
Certains réseaux mobiles doivent pouvoir agréger les routes (vers le routeur demandeur et le
réseau interne). Dans ce cas, le routeur demandeur doit utiliser le préfixe du réseau interne de
l'interface qui le relie au routeur délégataire. Il utilise alors deux des options du RFC 6603.
(l'annexe 4 présente la structure de l'option d'association d'identités pour la délégation de
préfixes).
Principe de l'allocation
Le routeur demandeur se comporte comme un client DHCPv6. Il émet un message SOLICIT
contenant une association d'identités pour l'allocation de préfixes à états, IA_PD. Le routeur
délégataire se comporte comme un serveur DHCPV6. Il alloue les préfixes en fonction de
l'identité du routeur demandeur et des options de préfixe indiquées (voir la figure 8).
Figure 9 : Allocation de préfixe par un routeur délégataire en présence d'un relais.
Conclusion
DHCPv6 est un protocole de niveau application. Il utilise le protocole de transport UDP et
fonctionne en mode client-serveur. Les messages échangés transportent l'identité de l'émetteur
(DUID), celle du récepteur, ou les deux, en fonction du sens de transmission du message et de
l'avancement de l'échange.
Ce protocole permet qu'un administrateur centralise et gère simplement les paramètres de
configuration du réseau, répercute les changements de configuration à l'initiative du serveur
DHCPv6 (renumérotation active), ou au contraire, laisse aux clients la possibilité de les prendre
en compte lorsqu'ils le souhaitent (renumérotation passive).
Il fonctionne sans relais lorsque le client et le serveur se trouvent sur le même lien. Il fait
intervenir des relais lorsque client et serveur sont sur des liens distincts.
Les relais utilisent des messages spécifiques pour communiquer avec les serveurs DHCPv6. Ils
encapsulent les messages relayés dans une option de "message relayé". Ainsi, les messages
des clients, ceux des serveurs, ou ceux des relais, ne sont jamais modifiés.
Lorsque les relais disposent d’informations locales, des options spécifiques des messages
RELAY-FORWARD leur permettent de les communiquer aux serveurs DHCPv6. Les serveurs
DHCPv6, en fonction de leur configuration par l’administrateur du réseau, peuvent alors
communiquer tout ou partie de ces informations à leurs clients.
Tous les paramètres de configuration du réseau sont transportés dans des options des
messages, ce qui fait de DHCPv6 un protocole extensible. Pour étendre le protocole, il suffit d’y
ajouter de nouvelles options. Ainsi, initialement, ni la délégation de préfixe ni l'exclusion de
préfixe n'existaient. Il a suffi de définir deux options supplémentaires et leur gestion en émission
et en réception pour ajouter cette nouvelle fonctionnalité dans DHCPv6.
Références bibliographiques
1. ↑ IANA. Protocol Registries Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Destination inaccessible
Un message ICMP Destination Unreachable est généré dès qu'un datagramme ne peut être
traité. Le format de ce message est présenté par la figure 3.
Délai expiré
Quand un routeur relaie un datagramme, il décrémente la valeur du nombre de sauts(Hop
Limit) de 1. Ce champ, dans l'en-tête IPv6, limite la durée de vie d'un paquet dans le réseau. La
durée de vie est exprimée en nombre de routeurs traversés (ou sauts). Si un routeur reçoit un
datagramme avec un nombre de sauts de 1, la décrémentation amène la valeur de ce
champ à zéro. Le routeur supprime le datagramme et en avertit la source à l'aide du message
Délai expiré (Time Exceeded) (voir la figure 5). Le signalement de cette erreur peut indiquer une
boucle dans le réseau au niveau du routage ou que l'émetteur a positionné une valeur de
nombre de sauts trop faible. Le dernier cas peut provenir d'un paquet émis par la
commande traceroute. Cette commande vise à déterminer le chemin pris par les
datagrammes [1].
Erreur de paramètre
Le message Parameter problem est émis quand un paquet IPv6 ne peut être traité par un nœud
du fait d'un problème dans l'en-tête du paquet ou dans ses extensions d'en-tête. Le paquet IPv6
est supprimé mais le nœud envoie à la source le message ICMPv6 dont le format est présenté
par la figure 6.
Rapport d'abonnement
143
MLDv2
Principe de MLD
Le routeur envoie régulièrement des messages de recensement général à l'adresse de
multicast FF02::1. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que
le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas
immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse
multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il
désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport
d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les
récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le
trafic MLD.
Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un
message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ;
contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les
récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :
• pour souscrire à une adresse multicast spécifique ;
• pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement
à l'adresse multicast de "tous les routeurs du lien local" (FF02::2). Le routeur répond
avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de
récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa
table de routage.
Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus
répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse
multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire.
Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il
s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.
À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce
cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul
responsable pour l'envoi des messages de recensement.
0 Commande
1 Résultat
140 Réponse
Sollicitation
Annonce du Sollicitation Annonce Indication de
du
Adresse physique de
présent présent présent
la source
Adresse physique de
présent présent
la cible
Information sur le
≥1
préfixe
MTU possible
5 MTU RA
11 CGA option
13 Timestamp option
14 Nonce option
16 Certificate option
Mobility options
SLAAC optimization
En-tête redirigée
MTU
Référence bibliographique
1. ↑ Wikipédia Principe de l'utilitaire traceroute
2. ↑ Kline, E. and Townsley, M.; Google IPv6 Center. ICMPv6 is Non-Optional
3. ↑ Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP :
principes et protocoles
4. ↑ IANA. IPv6 Neighbor Discovery Option Formats
Figure 11 : Format d'une option DNSSL prévu par la RFC 8106.
1. Le champ type a pour valeur 31.
2. Le champ length indique la longueur totale de l’option, champs type et longueur
inclus (en multiples de 8 octets). Le récepteur de cette option utilise ce champ pour
calculer le nombre d’adresses de serveurs DNS récursifs.
3. Le champ lifetime indique la durée de vie maximum, en seconde, des suffixes
associés. Les valeurs de ce champ permettent que la machine sache si elle peut utiliser
ces adresses, si leur durée de vie est infinie, si elle doit les rafraîchir ou si elle ne peut
plus les utiliser.
4. Le champ noms de domaines contient la liste des noms de domaines à utiliser pour
effectuer les résolutions directes.
Pour simplifier les choses, les noms de domaines ne sont pas compressés. Les bits
excédentaires sont mis à 0.
Figure 12 : format de l'option de DHCPv6 spécifiant la liste des serveurs DNS récursifs (RFC
8415).
Figure 13 : format de l'option de DHCPv6 spécifiant la liste des suffixes de nom de domaine
(RFC 8415).
1. Le code de l'option OPTION_DOMAIN_LIST vaut 24.
2. Le champ Longueur donne la longueur de l’option en octets.
3. Le champ Searchlist contient la liste de suffixes de noms de domaines.
Les noms de domaines ne sont pas compressés par souci de simplification. Ces deux options
ne peuvent apparaître que dans les messages DHCPv6 : SOLICIT, ADVERTISE, REQUEST,
RENEW, REBIND, INFORMATION-REQUEST et REPLY.
lecteur peut se référer à la comparaison des logiciels DNS sur Wikipedia. Par ailleurs, certaines
distributions logicielles comportent l'implémentation du client et du serveur. D'autres n'incluent
que l'implémentation du client ou que celle du serveur. Dans leurs versions récentes, la plupart
de ces logiciels DNS supportent complètement IPv6, c'est-à-dire à la fois au niveau de la base
de nommage (enregistrements AAAA et PTR) et au niveau du transport IPv6 des messages
DNS. Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de nommage.
Par exemple, l'ISC : Internet Systems Consortium développe la distribution BIND9 (Berkley
Internet Name Domain). Cette distribution représente la référence de fait dans le domaine. En
effet, il s'agit d'une pile logicielle complète : client, serveur et outils. Il intègre toutes les
extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 présentent l'avantage
d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes
(Unix, MS Windows, Apple...). Ainsi, la distribution BIND9 a été choisie comme base pour les
exemples de fichiers de configuration.
Notez que les logiciels DNS développés par les NLnetLabs sont aussi des logiciels libres et
qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir : serveur DNS
récursif ou officiel uniquement. Ainsi, de plus en plus d'opérateurs DNS utilisent aujourd'hui le
serveur récursif NSD comme serveur DNS officiel (sans récursion) et Unbound comme serveur
DNS récursif pour l'une et/ou l'autre de deux raisons : les performances et la diversité
générique. Les performances sont reconnues par des tests comparant, d'un côté, NSD et BIND,
et de l'autre, Unbound et BIND montrent la supériorité respective des premiers sur les seconds).
La diversité générique concerne la diversité des plates-formes logicielles supportant ces
serveurs DNS.
des serveurs primaires qui fournissent les fichiers de zone. L’outil named-checkconf vérifie les
fichiers de configuration du serveurs DNS secondaire. Notez qu'un serveur DNS secondaire
peut se synchroniser, soit à partir du serveur DNS primaire, soit à partir d'un serveur DNS
secondaire déjà synchronisé.
L’analyse du fichier journal (/var/log/syslog par exemple, sur un système Linux) donne des
indications précieuses sur les erreurs d’exécution relatives au service de nommage ou leur
absence.
La configuration des clients s’effectue au niveau du fichier (/etc/resolv.conf pour les systèmes
Linux, par exemple). Le fichier resolv.conf contient la déclaration du domaine, jusqu’à trois
adresses de serveurs DNS, et une liste de noms de domaines recherchés.
Il faut ensuite vérifier le bon fonctionnement des serveurs primaire et secondaires à l’aide d’un
client. La vérification se fait à l’aide des outils dig ou host, utilisables en ligne de commande.
Ces outils utilisent, par défaut, les informations contenues dans le fichier resolv.conf. Notez que
l’outil nslookup n’est plus maintenu. Son utilisation est désormais déconseillée. Nous ne
présentons donc pas ici son utilisation.
des correspondances nom-adresse des serveurs racines. Le serveur enregistre cette liste dans
un emplacement spécial de sa mémoire cache normale. Il n’est donc plus nécessaire de leur
associer une durée de vie. Pour obtenir les adresses des serveurs racine, établissez une
session ftp anonyme avec la machine ftp.rs.internic.net et rapatriez le fichier db.cache du
répertoire domain. Ce fichier change de temps en temps. Il est donc nécessaire,
périodiquement, d’en rapatrier localement une version à jour.
Dans le cas d’un service de nommage autonome, le serveur DNS primaire sert également de
serveur racine. Nous utilisons dans ce cas un fichier db.fakeroot au lieu du fichier db.cache.
include "/etc/bind/rndc-key";
controls {
inet 127.0.0.1 port 953
allow {127.0.0.1; ::1; } keys { "rndc-key"; };
};
L'option listen-on peut avoir plusieurs valeurs possibles. Avec la valeur any, le serveur écoute
sur toutes les adresses IPv4 opérationnelles. Si une liste d'adresses IPv4 est spécifiée, le
serveur écoutera uniquement les requêtes et réponses reçues sur chacune des interfaces
configurées avec une de ces adresses. Si la valeur none est spécifiée, cela signifie que le
serveur ne supporte pas IPv4.
Par défaut, le serveur DNS BIND 9 n’écoute pas les requêtes qui arrivent sur une interface
IPv6. Pour changer ce comportement par défaut, il faut utiliser l'option listen-on-v6. Si elle vaut
any le serveur écoute sur toutes les adresses IPv6 opérationnelles. Si une liste d'adresses IPv6
est spécifiée, le serveur écoutera uniquement les requêtes et réponses reçues sur chacune des
interfaces configurées avec une de ces adresses. La valeur par défaut est none, ce qui signifie
que le serveur ne supporte pas IPv6 (valeur par défaut).
};
};
//
// Déclaration des zones inverses
//
//
// 2001:db8:330f:a0d1::/64
//
zone "1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.131.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// 2001:db8:330f:a0d2::/64
//
zone "2.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.132.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// 2001:db8:330f:a0d3::/64
//
zone "3.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/bind/db.132.tpt.example.com.rev";
allow-transfer {
2001:db8:330f:a0d1::197;
2001:db8:330f:a0d2::197;
};
};
//
// Zones secondaires
//
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
Fichier db.131.tpt.example.com.rev
$TTL 3h
;
@ IN SOA s-13-v6.tpt.example.com. root.s- 13-
v6.tpt.example.com. (
2 ; Numéro de série
3600 ; rafraîchissement (1 heure)
900 ; Nouvelle tentative (15 minutes)
3600000 ; Durée de vie maximale (5 semaines 6 jours
et 16 heures)
1h ) ; Durée de vie minimale (1 heure)
;
@ IN NS s-13-v6.tpt.example.com.
@ IN NS r-13-v6.tpt.example.com.
$ORIGIN 1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.
3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com.
7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com.
7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r-13-v6.tpt.example.com.
Fichier db.132.tpt.example.com.rev
$TTL 3h
;
@ IN SOA s-13-v6.tpt.example.com. root.s-13-
v6.tpt.example.com. (
2 ; Numéro de série
3600 ; rafraîchissement (1 heure)
900 ; Nouvelle tentative (15 minutes)
3600000 ; Durée de vie maximale (5 semaines 6 jours
; et 16 heures)
1h ) ; Durée de vie minimale (1 heure)
;
@ IN NS s-13-v6.tpt.example.com.
@ IN NS r-13-v6.tpt.example.com.
$ORIGIN 2.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.
7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR r-13-v6.tpt.example.com.
Fichier db.133.tpt.example.com.rev
$TTL 3h
;
@ IN SOA s-13-v6.tpt.example.com. nobody.localhost.
(
4 ; Numéro de série
3600 ; rafraîchissement (1 heure)
900 ; Nouvelle tentative (15 minutes)
3600000 ; Durée de vie maximale (5 semaines 6 jours
et 16 heures)
1h ) ; Durée de vie minimale (1 heure)
;
@ IN NS s-13-v6.tpt.example.com.
@ IN NS r-13-v6.tpt.example.com.
$ORIGIN 3.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.
7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR s-13-v6.tpt.example.com.
terme résolveur. Rappelons que toutes les applications TCP/IP s'exécutant sur une machine
donnée sollicitent ce résolveur. Ce dernier les renseigne sur les ressources DNS nécessaires à
l'établissement de leur communication avec des applications distantes.
;; QUESTION SECTION:
;s-13-v6.tpt.example.com. IN AAAA
;; ANSWER SECTION:
s-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d1::53
s-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d1::217
s-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d2::217
s-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d3::217
s-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d4::217
;; AUTHORITY SECTION:
tpt.example.com. 10800 IN NS r-13-
v6.tpt.example.com.
tpt.example.com. 10800 IN NS s-13-
v6.tpt.example.com.
;; ADDITIONAL SECTION:
r-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d2::197
r-13-v6.tpt.example.com. 10800 IN AAAA
2001:db8:330f:a0d1::197
Exemple d’interrogation d’un serveur DNS avec la commande host : résolution directe
root@s-13-v6:/etc/bind# host -t aaaa s-13-v6.tp13.tptfctp.
s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d1::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d2::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d3::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d4::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:db8:330f:a0d1::53
Exemple d’interrogation d’un serveur DNS avec la commande dig : résolution inverse
root@s-13-v6:/etc/bind# dig @::1 -x 2001:db8:330f:a0d1::217
;; QUESTION SECTION:
;7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.
IN PTR
;; ANSWER SECTION:
7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa.
10800IN PTR s-13-v6.tp13.tptfctp.
;; AUTHORITY SECTION:
1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN NS r-13-v6.tp13.tptfctp.
1.d.0.a.f.0.3.3.8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN NS s-13-v6.tp13.tptfctp.
;; ADDITIONAL SECTION:
r-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d2::197
r-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::197
s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d2::217
s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d3::217
s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d4::217
s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::53
s-13-v6.tp13.tptfctp. 10800 IN AAAA 2001:db8:330f:a0d1::217
Exemple d’interrogation d’un serveur DNS avec la commande host : résolution inverse
root@r-13-v6:/var/bind# host -t aaaa s-13-v6
s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::53
s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d1::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d2::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d3::217
s-13-v6.tp13.tptfctp has IPv6 address 2001:660:330f:a0d4::217
root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d1::53
3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa
domain name pointer
s-13-v6.tp13.tptfctp.
root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d1::197
7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0.1.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa
domain name pointer
r-13-v6.tp13.tptfctp.
root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d2::197
7.9.1.0.0.0.0.0.0.0.0.0.0.0.0.0.2.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa
domain name pointer
r-13-v6.tp13.tptfctp.
root@r-13-v6:/var/bind# host -t aaaa 2001:660:330f:a0d3::217
7.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.3.d.0.a.f.0.3.3.0.6.6.0.1.0.0.2.ip6.arpa
domain name pointer
s-13-v6.tp13.tptfctp.
pratiques pour y faire face. Le chapitre qui suit, Deux impossibilités d’accéder au service de
nommage et remèdes, résume ces recommandations. Dans un article en ligne, l'auteur revient
sur des cas problématiques du déploiement du DNS en IPv6 [1].
Le DNS supporte les enregistrements A et AAAA, et ce, indépendamment de la version d'IP
utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par
ailleurs, en tant qu'application TCP/IP, un serveur DNS utilise les transports UDP sur IPv4 ou
IPv6 ou sur les deux à la fois (machine en double pile). Dans tous les cas, le serveur DNS doit
satisfaire une requête donnée en renvoyant les informations qu'il a dans sa base de données,
indépendamment de la version d'IP qui lui a acheminé cette requête.
Un serveur DNS ne peut pas, a priori, savoir si le résolveur initiateur de la requête l’a transmis à
son serveur récursif (cache) en utilisant IPv4 ou IPv6. Des serveurs DNS intermédiaires (cache
forwarder) peuvent, en effet, intervenir dans la chaîne des serveurs interrogés durant le
processus de résolution d’une requête DNS. Ces serveurs DNS intermédiaires (cache
forwarder) n'utilisent pas nécessairement la même version d'IP que leurs clients. Notez en
outre, qu’en supposant que le serveur DNS puisse connaître la version d'IP utilisée par le client
qui a initié la requête, il n'a pas à faire d'hypothèse sur l'usage par le client de la réponse DNS
renvoyée.
Glue IPv6
La zone racine publie également les adresses des différents serveurs DNS de chacun des
domaines racines (TLD : Top Level Domain). Ces adresses, appelées « glue » sont nécessaires
au démarrage du processus de résolution des noms.
En effet, rappelons que les serveurs DNS "racine" ne répondent pas eux-mêmes aux requêtes
des clients. Leur rôle est de faire le premier aiguillage (referal) vers des serveurs DNS "racine"
(TLD) : les serveurs DNS qui gèrent les domaines "racine" (TLD). Les informations d'aiguillage
incluent la liste des serveurs "racine" qui gèrent officiellement les informations de nommage
d'une zone. Elles incluent également les adresses (glues) de ces serveurs. Sans ces adresses,
la résolution ne peut se faire. Le client aurait le nom du serveur, mais pas son adresse et ne
pourrait l’obtenir…
En attendant que les serveurs "racine" puissent recevoir des requêtes DNS et répondre en
IPv6, les domaines "racine" TLD ont pendant des années milité pour l'introduction des « glues »
IPv6 qui leurs sont associées dans la zone racine. L'IANA/ICANN a fini par se convaincre que la
publication des adresses IPv6 des serveurs DNS "racine" supportant IPv6 pouvait se faire sans
risque pour la stabilité du DNS. L'ICANN/IANA a démarré, en juillet 2004, la publication des
adresses IPv6 des domaines "racine" TLD dans la zone racine. Les trois TLD .fr, .jp et .kr ont,
les premiers, vu leur glue IPv6 publiée. Aujourd’hui (en 2015), 10 serveurs DNS "racine"
fonctionnent en IPv6.
de celle des deux conditions qui est satisfaite la première. Les serveurs DNS secondaires
obtiennent une copie des fichiers de zone modifiés par le serveur DNS primaire par transfert de
zone. Ceci leur permet de prendre en compte les modifications dynamiques effectuées au
niveau du serveur.
Des serveurs tels que DHCP utilisent la mise à jour dynamique pour déclarer les
correspondances "nom – adresse" et "adresse – nom" allouées automatiquement aux
machines. La structure des messages DNS est modifiée pour les messages de mise à jour du
DNS. Certains champs sont ajoutés, d’autres sont surchargés. Ils utilisent alors la procédure
ns_update du résolveur. Ainsi, la commande nsupdate permet, sur un système Linux, les mises
à jour dynamiques du DNS en ligne de commande. Pour des raisons évidentes, les mises à jour
dynamiques du DNS utilisent des mécanismes de sécurité.
Conclusion
Le système de nommage est l'application client-serveur distribuée qui fonctionne à la plus
grande échelle qui soit. C’est un système de base de données hiérarchique. Il utilise un arbre
de nommage pour garantir l’unicité des noms de domaine. Il a été initialement conçu pour
stocker des correspondances directes (nom – adresse) et les correspondances inverses
(adresse – nom). Mais il peut, plus généralement, stocker tout type d’information ; en particulier,
celles concernant les agents de transfert ou serveurs de courrier ou les serveurs de noms.
Ce système privilégie la récupération d’information sur la fraîcheur de l’information remise. Un
serveur de nommage fournit une réponse, en fonction des données dont il dispose, sans
attendre la fin d’un transfert éventuel de zone. Pour pallier le délai de mise à jour des données
de zone du serveur DNS secondaire, un client DNS, un résolveur, peut demander à obtenir des
informations du serveur DNS primaire de la zone. Ce serveur est forcément à jour.
Un nom absolu correspond au chemin qui, dans l’arbre de nommage relie une feuille à la racine
de l’arbre de nommage. La racine sans nom de l’arbre de nommage est représentée par un
« . ». Un domaine est un nœud de l’arbre de nommage.
Le client du système de nommage, le résolveur, est unique pour une machine donnée. Il est
réalisé sous forme d’une bibliothèque de procédures. Il s’initialise à partir d’un fichier de
configuration ou d’informations fournies par un serveur DHCP ou encore d’options spécifiques
des annonces de routeur. Le fichier de configuration du résolveur s’appelle généralement
resolv.conf.
Le service de nommage est le seul pour lequel l’utilisation de l’adresse IP d’au moins un
serveur est obligatoire. L’utilisateur qui souhaite communiquer avec une machine distante
fournit généralement le nom de cette machine. Les applications TCP/IP utilisent les procédures
de la bibliothèque du résolveur pour obtenir l’adresse IP associée à ce nom. Une fois l’adresse
obtenue, elles peuvent établir une session en mode "avec" ou "sans connexion" avec cette
machine distante.
Le système de nommage associe une hiérarchie de serveurs de noms à l’arbre de nommage. A
chaque nœud de l’arbre correspond un serveur de nommage. Chaque serveur dispose d’un
pointeur vers chacun de ses fils et un pointeur vers son père. Chaque père connaît chacun de
ses fils. Pour équilibrer la charge, le serveur racine est répliqué.
Les enregistrements de ressources de type A, pour IPv4 et AAAA, pour IPv6, gèrent
respectivement les correspondances directes "nom – adresse" respectivement pour IPv4 et
pour IPv6. Ils permettent que les utilisateurs manipulent les noms des machines et non leurs
adresses. Dans le cas d’IPv6, cela évite que les utilisateurs aient à retenir des adresses IPv6
représentées en notation hexadécimale pointée.
La configuration d’un service de nommage en IPv6 suppose la configuration d’un serveur DNS
primaire et d’au moins un serveur DNS secondaire. Ces deux serveurs sont des serveurs DNS
officiels pour la zone concernée. Le serveur DNS primaire utilise des fichiers maîtres contenant
les informations de nommage direct et indirect. Ces fichiers sont enregistrés dans une mémoire
non volatile.
Le fichier de nommage direct, unique pour chaque zone, contient les correspondances "nom-
adresse" IPv4 et IPv6 pour toutes les machines de la zone. Le nommage inverse contient un
fichier par lien en IPv6 ou par sous-réseau en IPv4. Les serveurs DNS secondaires peuvent
enregistrer, dans une mémoire non volatile, une copie locale des fichiers de zone. L’IETF le
recommande fortement. Cette pratique, qui réplique la base de nommage, accélère le
démarrage des serveurs DNS secondaires et augmente la robustesse du service en cas de
panne catastrophique (ou non) du serveur DNS primaire.
Les outils de vérification de configuration named-checkconf et named-checkzone vérifient
respectivement l’absence d’erreur dans le fichier de configuration de BIND9 et dans les fichiers
de zone. L’analyse des fichiers journaux permet de vérifier l’absence d’erreur à l’exécution du
service. Le fichier journal est généralement /var/log/syslog par défaut sur un système Linux.
L’utilisateur vérifie le bon fonctionnement de la résolution directe et de la résolution inverse avec
les outils dig et host. ces commandes utilisent par défaut les informations du fichier resolv.conf.
Pour éviter la fragmentation de l’espace de nommage due à la coexistence d’IPv4 et d’IPv6, les
administrateurs de réseaux doivent configurer au moins un serveur dual ou un relais DNS dual
dans chaque zone.
Les mises à jour dynamiques du système de nommage ont été introduites pour que des
services comme DHCP puissent déclarer les correspondances directes et les correspondances
inverses des machines auxquelles ils attribuent noms et adresses. Elles utilisent des
mécanismes de sécurité pour interdire les modifications non autorisées du service DNS. Les
mises à jour atomiques ne sont effectuées que lorsque tous les prérequis d’une mise à jour sont
satisfaits. Sinon, elles ne le sont pas.
1. ↑ Evans R. (2015). Medium On DNS and IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA_TA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+
| |
. DHCP-relay-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option d’authentification
L'option d'authentification (Authentication 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 Authentication Code) qui
authentifie le message et, bien entendu, la valeur du condensé (128 bits, par exemple).
Rappel : le principe de l'authentification consiste à calculer un condensé (ou empreinte, ou
hash) 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 identiques, l'information est acceptable. Sinon, elle est rejetée.
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_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La structure de la partie "données" de cette option peut apparaître plusieurs fois. Elle est la
suivante :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
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.
Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un
client.
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_RSOO (66) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 : Format de l'option de préfixe d'associations d'identités pour la délégation de préfixe.