Difference between revisions of "MOOC:Annexe Compagnon Act34"

From Livre IPv6

(→‎Act.34 Annexe 2 : Options DNS du protocole DHCPv6)
 
(5 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
__NOTOC__
 
__NOTOC__
−
= ANNEXE 1 Activité 34 :  Faire correspondre adresse et nom de domaine =
 
  
−
==Options DNS des RA ==
+
= ANNEXE 3 Activité 34 : Format DHCPv6 =
−
===Option de liste de serveurs DNS récursifs (RDNSS)===
+
  
−
Cette option d’annonce de routeur contient l’adresse IPv6 d’un ou plusieurs serveurs DNS récursifs (cf. figure 10).
+
==Structure des options du protocole DHCPv6 ==
 +
La structure générale des options est décrite ci-dessous. Elle correspond à un codage TLV : type, longueur, valeur.
  
−
<center>
+
Le type ou code est un entier non signé. Il précise quelle est l’option. La longueur de l’option précise la taille en nombre d'octets du champs de données de l’option. Le champ <tt>type</tt> de l'option en est exclu. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.
−
[[Image:MOOC_Act34_Fig1.png|400px|center|thumb|Figure 10 : Format d'une option RDNSS de la RFC 8106.]]
+
−
</center>  
+
  
−
# Le champ <tt>type</tt> a pour valeur 25.
+
La portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'une association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.
−
# Le champ <tt>longueur</tt> indique la longueur totale de l’option. Les champs <tt>type</tt> et <tt>longueur</tt> sont inclus (en multiples de 8 octets). Ce champ permet à l’utilisateur de calculer facilement le nombre d’adresses de serveurs DNS récursifs.
+
−
# Le champ <tt>durée de vie</tt> indique la durée de vie maximum (en secondes) des adresses associées. 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.
+
−
# Le champ <tt>addresses</tt> contient les adresses IPv6 des serveurs DNS récursifs, codées sur 128 bits.
+
  
−
===Option de liste de domaines recherchés (DNSSL)===
+
La structure générale d'une option est la suivante :
  
−
L’option DNSSL contient un ou plusieurs suffixes de noms de domaines (cf. figure 11). Tous ces suffixes ont la même durée de vie. Certains suffixes peuvent avoir des durées de vies différentes s'ils sont contenus dans des options DNSSL différentes.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|        option-code          |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                        option-data                          |
 +
|                    (option-len octets)                       |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
<center>
+
−
[[Image:MOOC_Act34_Fig2.png|400px|center|thumb|Figure 11 : Format d'une option DNSSL prévu par la RFC 8106.]]
+
=== Option d'identification du client ===
−
</center>
+
L'option d'identification du client (''Client Identifier Option'') transporte le DUID (''DHCPv6 User Identification'') du client dans les messages DHCPv6 échangés entre client et serveur.
  
−
# Le champ <tt>type</tt> a pour valeur 31.
+
La structure de cette option est la suivante :
−
# Le champ <tt>length</tt> indique la longueur totale de l’option, champs <tt>type</tt> et <tt>longueur</tt> 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.
+
−
# Le champ <tt>lifetime</tt> 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.
+
−
# Le champ <tt>noms de domaines</tt> 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.
+
  0                   1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|        OPTION_CLIENTID      |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                              .
 +
.                            DUID                              .
 +
.                          (variable length                    .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
== Options DNS du protocole DHCPv6==
+
=== Option identification du serveur (''Server Identification Option'') ===
−
===Option serveur de nom récursif de DHCPv6===
+
L'option "identification du serveur" (''Server Identification Option'') transporte le DUID (''DHCPv6 User Identification'') du serveur dans les messages DHCPv6 échangés entre client et serveur.
  
−
L’option de serveur DNS récursif de DHCPv6 fournit, par ordre de préférence, une liste d’adresses IPv6 de serveurs DNS récursifs à une machine IPv6. La structure de l’option est la suivante (cf. figure 12) :
+
La structure de cette option est la suivante :
−
# Le champ <tt>OPTION_DNS_SERVERS</tt> vaut le code 23.
+
−
# Le champ <tt>longueur</tt> représente la longueur de l’option et elle est exprimée en multiple de 16 octets. La valeur du champ indique le nombre d’adresses de serveurs DNS récursifs contenu dans l’option.
+
−
# Le champ <tt>DNS-recursive-name-server</tt> contient l’adresse IPv6 d’un serveur DNS récursif. Il peut apparaître plusieurs fois.
+
  
−
<center>
+
  0                  1                  2                  3
−
[[Image:MOOC_Act34_Fig3.png|400px|center|thumb|Figure 12 : format de l'option de DHCPv6 spécifiant la liste des serveurs DNS récursifs (RFC 3315).]]
+
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
−
</center>
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
| OPTION_SERVERID                | option-len                  |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                              .
 +
.                              DUID                            .
 +
.                        (variable length)                     .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
===Option liste de suffixes de nom de domaine===
+
=== Option association d’identité pour les adresses non temporaires ===
 +
L'option "association d’identité" pour les adresses non temporaires (option IA_NA : ''Identity Association for Non Temporary Addresses'') inclut les paramètres de cette association et les adresses non temporaires associées. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6.
  
−
Le RFC 3315 prévoit également une option spécifiant la liste des suffixes de noms de domaines (cf. figure 13).
+
Cette association transporte un identificateur d'IA_NA, les temporisations T1, durée de vie préférée d'une adresse, et T2, durée de vie maximum d'une adresse, et les options de cette association, par exemple la liste des options d'adresse spécifiques de cette association.
  
−
<center>
+
La structure de cette option est la suivante :
−
[[Image:MOOC_Act34_Fig4.png|400px|center|thumb|Figure 13 : format de l'option de DHCPv6 spécifiant la liste des suffixes de nom de domaine (RFC 3315).]]
+
−
</center>
+
  
−
# Le code de l'option <tt>OPTION_DOMAIN_LIST</tt> vaut 24.
+
  0                  1                  2                  3
−
# Le champ <tt>Longueur</tt> donne la longueur de l’option en octets.  
+
  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
−
# Le champ <tt>Searchlist</tt> contient la liste de suffixes de noms de domaines.  
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|            OPTION_IA_NA      |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                      IAID (4 octets)                          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                              T1                              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                              T2                              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                                                              |
 +
.                          IA_NA-options                        .
 +
.                                                               .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
Les noms de domaines ne sont pas compressés par souci de simplification.
+
=== Option d'association d’identité pour les adresses temporaires ===
−
Ces deux options ne peuvent apparaître que dans les messages DHCPv6 : SOLICIT, ADVERTISE, REQUEST, RENEW, REBIND, INFORMATION-REQUEST et REPLY.
+
L'option d'association d’identité pour les adresses temporaires (option IA_TA : ''Identity Association for Temporary Addresses'') inclut les paramètres de cette association et au plus une adresse temporaire associée par préfixe autorisé sur le lien du client. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6. Une option statut indique l'état de toute opération impliquant cette option.
  
−
= Act.34 Annexe 3 : =
+
La structure de cette option est la suivante :
−
==Mises en œuvre du service DNS ==
+
  
−
Cette partie présente les principaux logiciels supportant IPv6. Elle renvoie vers une liste plus complète de logiciels. Elle détaille ensuite comment configurer un service de nommage autonome en IPv6. Elle donne également des exemples de fichiers de configuration.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|            OPTION_IA_TA      |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                        IAID (4 octets)                      |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                                                              |
 +
.                         IA_TA-options                        .
 +
.                                                               .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
===Logiciels DNS supportant IPv6 ===
+
=== Option d’adresse d'association d'identités ===
 +
L'option d'adresse d'association d'identités (IA ''Address Option'') spécifie une adresse IPv6 associée à une association d'identités IA_NA ou IA_TA. Elle apparaît dans le champ d'option d'une association d'identités pour adresse non temporaire ou temporaire. Une option statut indique l'état de toute opération impliquant cette adresse.
  
−
De nombreux logiciels DNS existent aujourd'hui, mais cette section ne les liste pas de manière exhaustive. Pour avoir une idée plus claire du nombre et de la diversité de ces logiciels, le 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.
+
La structure de cette option est la suivante :
  
−
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.  
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|          OPTION_IAADDR        |        option-len            |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                                                              |
 +
  |                        IPv6 address                          |
 +
|                                                              |
 +
|                                                              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                    preferred-lifetime                        |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                      valid-lifetime                          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                               .
 +
.                       IAaddr-options                          .
 +
.                                                               .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
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.
+
=== Option de demande d’options ===
 +
L'option de demande d'option (''Options Request Option'') identifie la liste des options demandées par le client ou fournies ou concernées pour le serveur.
  
−
===Principe de configuration d’un serveur DNS ===
+
La structure de cette option est la suivante :
  
−
Cette partie présente le principe de configuration d’un service DNS autonome. Elle précise également les modifications à effectuer pour relier ce service DNS au service de nommage de l’Internet. Pour configurer un service de nommage, il faut successivement installer le paquetage du serveur de nommage sur les machines "serveur", configurer un serveur DNS primaire, configurer au moins un serveur DNS secondaire et préparer le fichier de configuration des clients du service de nommage.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|          OPTION_ORO          |        option-len            |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|    requested-option-code-1    |    requested-option-code-2    |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                              ...                             |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
La configuration du serveur DNS primaire comprend la configuration des options de fonctionnement du serveur, la configuration du fichier de résolution directe et la configuration des fichiers de résolution inverse. Deux outils vérifient la configuration du serveur. Le premier, ''named-checkconf'', vérifie l’absence d’erreur dans le fichier de configuration du serveur. Le second, ''named-checkzone'', vérifie l’absence d’erreur dans les fichiers de zone du serveur. Il utilise le nom de la zone et le fichier de zone correspondant. En cas d’erreur, ces outils signalent et localisent les erreurs. Ils facilitent donc la mise au point du service. Il faut également déclarer, au niveau du serveur DNS primaire, les serveurs DNS secondaires autorisés à se synchroniser.  
+
== Option de priorité (du serveur) ==
 +
L'option de priorité (''Preference Option'') indique la priorité du serveur au client.  
  
−
La configuration du serveur DNS secondaire comprend la configuration des options de fonctionnement du serveur, la déclaration du statut (secondaire) du serveur, la déclaration du ou 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é.
+
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.
  
−
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 structure de cette option est la suivante :
  
−
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.
+
  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  |
 +
+-+-+-+-+-+-+-+-+
  
−
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.
+
=== Option "temps écoulé" (depuis le début d'un échange) ===
 +
L'option "temps écoulé" mesure le temps écoulé (''Elapsed Time Option'') depuis l'émission du premier message d'un échange DHCPv6 inachevé. Cette option vaut 0 dans le premier message d'un échange.  
  
−
===Définition des fichiers de zone===
+
Serveurs et agents utilisent la valeur de cette option pour déterminer leur façon de traiter le message DHCPv6 correspondant. La valeur ffff en hexadécimal (0xffff) représente une durée supérieure à la plus grande durée représentable.
  
−
Les fichiers de zone contiennent principalement des enregistrements de ressources (''RR resource record''). Notez que les recherches ignorent la casse des caractères. Cependant, le DNS conserve la casse des caractères. Les commentaires commencent avec un « ; », et se terminent à la fin de la ligne. Les fichiers de zones sont plus faciles à lire s’ils sont documentés. L’ordre des enregistrements n’a aucune importance. Les enregistrements de ressources doivent commencer dans la première colonne d’une ligne.
+
La structure de cette option est la suivante :
  
−
La première étape de la configuration d’un serveur DNS primaire correspond à la conversion de la table des machines (fichier ''hosts'') en son équivalent pour le DNS : fichier de résolution directe (nom-adresse). Un outil écrit en langage Perl, ''h2n'', effectue automatiquement cette conversion à partir du fichier ''/etc/hosts'' pour une machine Linux.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|      OPTION_ELAPSED_TIME    |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|        elapsed-time          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
La seconde étape correspond à la production des fichiers de résolution inverse. Il y en a un par lien (fichiers de résolution inverse, adresse-nom). Dans le cas d’IPv6, un outil, ''ipcalc'', disponible sous la forme d’un paquet Linux, assure la conversion d’une adresse IPv6 en quartets. Un quartet correspond à un chiffre hexadécimal. Il sert pour la résolution inverse des noms en IPv6.  
+
=== Option "message relayé" ===
 +
L'option "message relayé" (''RELAY Message Option'') contient le message DHCPv6 relayé dans un message RELAY-FORWARD ou RELAY-REPLY.  
  
−
Le serveur DNS primaire a un fichier de résolution inverse pour l’adresse de boucle locale. Chaque serveur, primaire ou secondaire, est maître pour cette zone. En effet, personne n’a reçu la délégation pour le réseau <tt>127/24</tt>, ni pour <tt>::1/128</tt>. Chaque serveur doit donc en être responsable.  
+
Le message relayé, dans le cas d'un message qui transite du client vers le serveur, est soit le message DHCPv6 du client (premier relais), soit le message RELAY-FORWARD du relais précédent (du deuxième relais au dernier).
  
−
Le fichier de configuration du serveur de nommage, ''named.conf'', relie les domaines dont le serveur a la responsabilité administrative à leur fichier de zone respectif.  
+
Le message relayé dans le cas d'un message qui transite du serveur vers le client est, soit le message REPLY du serveur (premier relais), soit le message RELAY-REPLY du relais précédent (du deuxième relais au dernier).
  
−
Un serveur DNS doit également connaître les adresses des serveurs racines. Il utilise les informations du fichier ''db.cache'' pour interroger les serveurs et leur demander une liste à jour 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.
+
La structure de cette option est la suivante :
  
−
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''.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|      OPTION_RELAY_MSG        |            option-len        |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                                                              |
 +
.                       DHCP-relay-message                      .
 +
.                                                               .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
===Types d’enregistrement de ressource DNS===
+
=== 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.
  
−
Les principaux enregistrements de ressources du DNS sont de deux types : ceux relatifs à la zone et ceux relatifs aux machines.
+
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).
  
−
Les enregistrements relatifs à la zone sont : SOA, NS et MX.  
+
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.
  
−
* L'enregistrement de ressource SOA (''Start Of Authority'') indique qui est le serveur DNS primaire officiel de la zone. Il n’y en a qu’un par zone. La syntaxe de l’enregistrement SOA est la suivante : SOA, nom du serveur DNS primaire officiel, adresse mail de l’administrateur du service de noms, numéro de série, délai de rafraîchissement, délai avant nouvel essai, délai d’expiration de l’information, durée maximum de conservation d’une réponse négative dans le cache d’un serveur de nommage.
+
La sécurisation des échanges DHCPv6 entre serveurs et relais adjacents utilise IPsec.  
  
−
* L'enregistrement de ressource ''NS (Name Server)'' désigne un serveur DNS officiel pour la zone. Il y a autant d’enregistrements NS que de serveurs DNS officiels pour une zone donnée. Notez que certains serveurs DNS officiels de la zone peuvent ne pas être déclarés dans les fichiers de zone. il s'agit de serveurs DNS furtifs.
+
La structure de cette option est la suivante :
−
* L'enregistrement de ressource ''MX (Mail eXchanger)'' désigne un agent de transfert ou un serveur de courrier officiel pour un domaine donné.
+
  
−
Les principaux enregistrements relatifs aux machines de la zone sont : A, AAAA, PTR et CNAME.  
+
  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)                      .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
* L'enregistrement de ressource ''A'' définit une correspondance nom-adresse IPv4.
+
=== Option d’utilisation de l'adresse individuelle du serveur ===
−
* L'enregistrement de ressource ''AAAA'' définit une correspondance nom-adresse IPv6.
+
L'option d'utilisation de l'adresse individuelle du serveur (''Server Unicast Option'') qu'envoie un serveur, autorise le client DHCPv6 qui reçoit cette option à échanger avec le serveur en utilisant son adresse individuelle au lieu de l'adresse de diffusion sélective All_DHCP_Relay_Agents_and_Servers address.
−
* L'enregistrement de ressource ''PTR'' définit une correspondance inverse, adresse-nom. Les pointeurs ne désignent que le nom canonique d’une machine.<br/>
+
−
* L'enregistrement de ressource ''CNAME'' définit une corespondance entre le nom canonique d'une ressource (A ou AAAA) et un nom secondaire surnom (alias) d’une machine.
+
  
−
===Configuration de serveur DNS ===
+
La structure de cette option est la suivante :
−
Même si les logiciels DNS utilisés interfonctionnent, la syntaxe et les règles de configuration varient considérablement d'une implémentation à l'autre. Dans ce chapitre, nous fournissons des exemples suivant la syntaxe et les règles de configuration de BIND 9. Ce logiciel est aujourd'hui considéré comme mise en oeuvre de référence en matière de DNS.
+
  
−
===Réseau virtualisé utilisé pour générer ces exemples ===
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|          OPTION_UNICAST      |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                                                              |
 +
|                      server-address                          |
 +
|                                                              |
 +
|                                                              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
Les exemples de fichiers qui suivent ont été configurés dans un environnement réseau incluant trois machines supportant respectivement un serveur, un relais et un client DNS (cf. figure 14). La machine serveur '''s-13-v6''' supporte le serveur DNS primaire. Elle est également un routeur. Elle donne accès à un réseau A sur lequel se trouve le relais. Le réseau A sert pour faire de l’autoconfiguration DHCPv6 "à état" sans relais. Elle donne également accès au réseau C. Le réseau C sert pour l’autoconfiguration des adresses IPv6 (sans serveur DHCPv6). Le relais '''r-13-v6''' supporte un serveur DNS secondaire. Cette machine est également un routeur. Cette machine donne accès au réseau B. Le réseau B sert pour faire de l’autoconfiguration "à état" en présence d’un relais DHCPv6. Le client '''c-13-v6''' est doté de deux interfaces de réseau. La première est connectée soit au réseau A, soit au réseau B pour faire du DHCPv6, respectivement, sans et avec relais. La seconde est connectée au réseau C pour faire de l’autoconfiguration "sans état".
+
=== Option de code d’état ===
 +
L'option code d'état (''Status Code Option'') renvoie une indication d'état relative au message DHCPv6 ou à l'option dans laquelle cette option apparaît. L'omission du code d'état dans un message ou dans une option où son utilisation est possible signifie "succès".
  
−
<center>
+
La structure de cette option est la suivante :
−
[[Image:MOOC_Act34_figBJ-17.png|666px|thumb|center|Figure 14 : Réseau virtualisé pour générer ces exemples.]]
+
−
</center>
+
  
−
La configuration DNS proposée correspond à un domaine DNS autonome où le serveur DNS primaire fait également fonction de serveur DNS racine.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|      OPTION_STATUS_CODE      |            option-len        |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|        status-code            |                              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |
 +
.                                                               .
 +
.                        status-message                        .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
====Fichier de configuration d'un serveur BIND9 ====
+
L'annexe 2 présente les valeurs des différents codes d'état.
  
−
La configuration d’un serveur DNS primaire BIND9 concerne quatre aspects : la configuration des options de fonctionnement du serveur, la configuration du fichier de zone pour la résolution directe (nom – adresse), la configuration des fichiers de zone pour la résolution inverse (adresse – nom), et la mise au point du service.
+
=== Option de Validation rapide  ===
−
<!--Il y a, en IPv6, un fichier de résolution inverse par lien dans la zone.-->
+
L'option de validation rapide (''Rapid Commit Option'') indique l'utilisation d'un échange à deux messages pour l'allocation d'adresses IPv6. Le principe de cette allocation est le suivant :
−
Pour tenir compte de cette modularité, le fichier principal de configuration de BIND9 se contente d’inclure d’autres fichiers gérant spécifiquement chacun des aspects précédents. Le fichier de configuration du serveur de nom BIND 9 est, par exemple sous Linux, ''/etc/bind9/named.conf''. Ce fichier se contente d’inclure d’autres fichiers. Chacun de ces fichiers contient un ensemble de déclarations relatives à un aspect de la configuration du serveur.
+
  
−
====Exemple de contenu du fichier ''/etc/bind9/named.conf''====
+
(1) Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.
  
−
// This is the primary configuration file for the BIND DNS server named.  
+
(2) Un serveur doit inclure cette option dans le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.
−
//
+
−
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
+
−
// structure of BIND configuration files in Debian, *BEFORE* you customize
+
−
// this configuration file.
+
−
//
+
−
// If you are just adding zones, please do that in /etc/bind/named.conf.local
+
−
include "/etc/bind/named.conf.options";
+
−
include "/etc/bind/named.conf.local";
+
−
include "/etc/bind/named.conf.default-zones";
+
  
−
====Configuration du fonctionnement du serveur====
+
La structure de cette option est la suivante :
  
−
Le fichier ''named.conf.options'' contient, par exemple, différentes options de configuration du fonctionnement du serveur, telles que le répertoire de travail, l'activation de l'écoute des requêtes DNS sur un port (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif, l’affichage ou non du numéro de version du serveur.
+
  0                  1                  2                  3
 +
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|      OPTION_RAPID_COMMIT    |              0              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
====Contenu du fichier ''named.conf.options''====
+
=== Option classe d'utilisateur ===
 +
L'option classe d'utilisateur (''User Class Option'') identifie un type ou une classe d'utilisateurs ou d'applications qu'ils représentent. La partie données de cette option contient plusieurs champs non interprétés (''opaque'') par DHCPV6. Ces champs représentent la classe d'utilisateur à laquelle appartient le client.
  
−
options {
+
Un serveur choisit les informations de configuration du client en fonction de la classe identifiée par l'option.
−
        directory "/var/bind";
+
−
auth-nxdomain no;
+
−
listen-on { any; };
+
−
  listen-on-v6 { any; };
+
−
version none;
+
−
allow-query-cache { any; };
+
−
  allow-query { any; };
+
−
allow-recursion {
+
−
              2001:db8:330f:a0d1::/64;
+
−
              2001:db8:330f:a0d2::/64;
+
−
              2001:db8:330f:a0d1::/64;
+
−
              };
+
−
};
+
−
+
−
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.
+
La structure de cette option est la suivante :
−
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).
+
  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
−
 
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
====Exemple de configuration locale du serveur de noms BIND9====
+
  |        OPTION_USER_CLASS    |        option-len            |
−
 
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
Le fichier ''named.conf.local'' contient les chemins d’accès aux zones pour lesquelles le serveur DNS est maître officiel (master). Il définit également le chemin d'accès aux données (option directory) et le rôle du serveur DNS pour chacune des zones (primaire ou secondaire). Les zones DNS pour lesquelles le serveur DNS (primaire ou secondaire) est officiel sont ensuite déclarées successivement grâce à des rubriques de type "zone". Pour chaque zone, le nom du fichier contenant les enregistrements de chaque zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, l’administrateur du réseau indique (à l'aide de la sous-rubrique ''slave'') la liste des adresses IPv4 et/ou IPv6 des serveurs DNS, primaire ou secondaires, à partir desquels ce secondaire peut se synchroniser.
+
  .                                                               .
−
 
+
  .                        user-class-data                      .
−
Voici maintenant un extrait du fichier ''named.conf.local'' de notre serveur DNS autonome.
+
  .                                                               .
−
 
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
====Exemple de contenu du fichier ''named.conf.local''====
+
−
 
+
−
//
+
−
// Do any local configuration here
+
−
//
+
−
// Consider adding the 1918 zones here, if they are not used in your
+
−
// organization
+
−
//
+
−
include "/etc/bind/zones.rfc1918";
+
−
//zones primaires
+
−
//
+
−
//
+
−
//
+
−
// Déclaration de la zone tpt.example.com
+
−
//
+
−
//
+
−
zone "tpt.example.com" {
+
−
type master;
+
−
file "/etc/bind/db.tpt.example.com";
+
−
allow-transfer {
+
−
2001:db8:330f:a0d1::197;
+
−
2001:db8:330f:a0d2::197;
+
−
};
+
−
};
+
−
//
+
−
// 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
+
−
  //
+
−
 
+
−
====Contenu du fichier ''named.conf.default-zones''====
+
−
 
+
−
  // prime the server with knowledge of the root servers
+
−
  zone "." {
+
−
type hint;
+
−
file "/etc/bind/db.fakeroot";
+
−
  };
+
 
   
 
   
−
// be authoritative for the localhost forward and reverse zones, and for
+
La structure de la partie "données" de cette option peut apparaître plusieurs fois. Elle est la suivante :
−
// 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 de zone DNS pour la résolution directe (nom - adresse) ====
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
 +
|      user-class-len          |          opaque-data        |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
  
−
Voici, à titre d'exemple, un extrait du fichier de résolution directe pour la zone ''tpt.example.com''. Il ne fait apparaître que les adresses IPv6. Notez, dans cet exemple, que les adresses IPv6 ont été construites manuellement pour garantir leur pérennité dans le DNS. En effet, rappelons dans ce contexte que les adresses obtenues par auto-configuration dérivent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291). Notez également que pour que ces adresses soient automatiquement prises en compte dans le DNS, il faudrait configurer et autoriser la mise à jour dynamique du service de nommage depuis ces machines.
+
=== Option de classe de constructeur ===
 +
L'option de classe de constructeur (''Vendor Class Option'') identifie le constructeur du matériel qui supporte le client DHCPv6. Le numéro d'entreprise identifie le constructeur.
  
−
$TTL 3h
+
La structure de cette option est la suivante :
−
tpt.example.com. IN SOA s-13-v6.tpt.example.com. r-13-v6.tpt.example.com. (
+
−
3 ; numéro de série
+
−
3600 ; refresh (1 heure)
+
−
900 ; nouvel essai (15 minutes)
+
−
3600000 ; expiration (5 semaines jours 16 heures)
+
−
1h) ; durée de vie minimum (1 heure)
+
−
@ IN NS s-13-v6.tpt.example.com.
+
−
@ IN NS r-13-v6.tpt.example.com.
+
−
+
−
s-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::217
+
−
AAAA 2001:db8:330f:a0d1::53
+
−
AAAA 2001:db8:330f:a0d2::217
+
−
AAAA 2001:db8:330f:a0d3::217
+
−
  AAAA 2001:db8:330f:a0d4::217
+
−
r-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::197
+
−
AAAA 2001:db8:330f:a0d2::197
+
−
c-13-v6.tpt.example.com. IN AAAA 2001:db8:330f:a0d1::187
+
−
AAAA 2001:db8:330f:a0d2::187
+
−
s13.tpt.example.com. IN CNAME s-13-v6.tpt.example.com.
+
−
r13.tpt.example.com. IN CNAME r-13-v6.tpt.example.com.
+
−
c13.tpt.example.com. IN CNAME c-13-v6.tpt.example.com.
+
  
−
===Fichier de zone DNS inverse en IPv6 ===
+
  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_VENDOR_CLASS      |        option-len            |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                      enterprise-number                      |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                              .
 +
.                      vendor-class-data                      .
 +
.                                                              .
 +
.                                                              .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
Voici les fichiers de zone pour la résolution DNS inverse correspondant au préfixe IPv6 d’un lien.  
+
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.
  
−
====Fichier ''db.131.tpt.example.com.rev''====
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
 +
|        vendor-class-len      |      opaque-data              |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
  
 +
=== Option d'information spécifique d'un constructeur ===
 +
L'option d'information spécifique d'un constructeur (''Vendor-specific Information Option'') permet que les clients et serveurs DHCPv6 échangent des informations spécifiques d'un constructeur. Le numéro d'entreprise identifie le constructeur.
  
−
$TTL 3h
+
La structure de cette option est la suivante :
−
;
+
−
@ 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''====
+
  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_VENDOR_OPTS      |            option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|                      enterprise-number                      |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                               .
 +
.                         option-data                          .
 +
.                                                               .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
$TTL 3h
+
La spécification des données échangées dépend du constructeur. Chacune de ces options de données est codée en format TLV. Le constructeur définit leur code. Plusieurs options de données peuvent se succéder dans le champ de données de l'option d'information spécifique d'un constructeur.
−
;
+
−
@ 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''====
+
La structure de l'option de donnée spécifique d'un constructeur est la suivante :
  
−
$TTL 3h
+
  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
−
;
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
@ IN SOA s-13-v6.tpt.example.com. nobody.localhost. (
+
  |            opt-code          |            option-len          |
−
4 ; Numéro de série
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
3600 ; rafraîchissement (1 heure)
+
.                                                               .
−
900 ; Nouvelle tentative (15 minutes)
+
  .                         option-data                          .
−
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.
+
  
−
===Clients du service de nommage===
+
=== Option d'identification d'interface ===
 +
L'option d'identification d'interface (''Interface-Id Option'') identifie, sur un relais, l'interface de réception du message d'un client.
  
−
Un client DNS, un résolveur, se présente souvent sous la forme d'une bibliothèque de nommage. Cette dernière se nomme ''libresolv''. Ce client est appelé ''resolver''. Nous utilisons le 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.  
+
Un relais qui reçoit un message incluant une option d'identification d'interface relaie le message reçu sur l'interface identifiée dans l'option.
  
−
====Exemple de fichier de configuration ''/etc/resolv.conf'' d’un serveur de noms====
+
Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option est spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cette information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.
  
−
domain tpt.example.com
+
La structure de cette option est la suivante :  
−
nameserver ::1
+
−
nameserver 2001:db8:330f:a0d1::53
+
−
nameserver 2001:db8:330f:a0d1::217
+
−
search tpt.example.com
+
  
−
====Exemple de fichier de configuration ''/etc/resolv.conf'' d’une machine====
+
    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_INTERFACE_ID      |            option-len        |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
.                                                               .
 +
.                        interface-id                          .
 +
.                                                              .
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
−
domain tpt.example.com
+
=== Option de message de reconfiguration ===
−
nameserver 2001:db8:330f:a0d1::197
+
L'option de message de reconfiguration (''Reconfigure Message Option''), présente dans un message de reconfiguration issue d'un serveur, indique au client s'il doit répondre à l'aide d'un message RENEW ou INFORMATION-REQUEST. Cette option est spécifique du message de reconfiguration.
−
nameserver nameserver 2001:db8:330f:a0d1::53
+
−
nameserver 2001:db8:330f:a0d1::217
+
−
search tpt.example.com
+
  
−
===Outils de vérification de la configuration DNS===
+
La structure de cette option est la suivante :
  
−
Outre le résolveur, des outils et commandes dépendent des systèmes d'exploitation existants. Ces outils permettent d'interroger un serveur DNS pour le mettre au point et/ou le dépanner. Les outils ''dig'' et '' host'', par exemple, font partie des distributions BIND9. Nous présentons des exemples de leur utilisation dans la suite de cette partie.
+
  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_RECONF_MSG      |          option-len          |
 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 +
|    msg-type  |
 +
+-+-+-+-+-+-+-+-+
  
−
Notez que, lorsque le serveur interrogé n'est pas explicitement renseigné lors de l’invocation de ces commandes, les serveurs par défaut référencés dans le fichier ''resolv.conf'' sont interrogés. Il peut, par exemple, s'agir de la liste des serveurs récursifs configurée automatiquement (via DHCP, par exemple) ou de celle configurée manuellement dans un fichier de configuration (''/etc/resolv.conf'' pour les systèmes Unix ou Linux) ou via une interface graphique de l’équipement (MS Windows et Mac OS). Les mécanismes de découverte de la liste des serveurs DNS récursifs sont décrits plus loin. Voir le chapitre '''Découverte de la liste de serveurs DNS récursifs'''.
+
=== Option d'acceptation de reconfiguration ===
 +
L'option d'acceptation de reconfiguration (''Reconfigure Accept Option'') annonce au serveur que le client accepte les messages de reconfiguration.
  
 +
Un serveur utilise cette option pour dire au client s'il doit ou non accepter les messages de reconfiguration. L'absence de cette option indique le refus d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messages de reconfiguration.
  
−
====Exemples d'interrogation d’un serveur DNS avec ''dig'' : résolution directe ====
+
La structure de cette option est la suivante :
  
−
  root@s-13-v6:/etc/bind# dig @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa
+
  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
−
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @2001:db8:330f:a0d1::53 s-13-v6.tpt.example.com -t aaaa
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
; (1 server found)
+
  |      OPTION_RECONF_ACCEPT    |                0             |
−
;; global options: +cmd
+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
−
;; Got answer:
+
−
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10043
+
−
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 2
+
−
+
−
;; 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
+
−
   
+
−
;; Query time: 0 msec
+
−
  ;; SERVER: 2001:db8:330f:a0d1::53#53(2001:db8:330f:a0d1::53)
+
−
;; WHEN: Wed Feb 25 00:55:58 2015
+
−
;; MSG SIZE rcvd: 270
+
  
−
====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution directe====
+
=== Extension du protocole DHCPv6 : options spécifiques des relais ===
 +
Dans certains cas, les relais DHCPv6  connaissent des informations qui seraient utiles aux clients DHCPv6.
  
−
root@s-13-v6:/etc/bind# host -t aaaa s-13-v6.tp13.tptfctp.
+
Le protocole DHCPv6 est étendu (RFC 6422) pour que les relais puissent inclure une option RSSO : RELAY-SUPPLIED OPTIONS OPTION dans les messages RELAY-FORW adressés au serveur DHCPv6.
−
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====
+
L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORWARD adressés au serveur DHCPv6 contient alors toutes les options correspondant à des paramètres que le relais souhaite porter à la connaissance du client. Cette possibilité n’est effective que pour des paramètres classés RSOO. 
  
−
root@s-13-v6:/etc/bind# dig @::1 -x 2001:db8:330f:a0d1::217
+
Le serveur DHCPv6 qui reçoit un message RELAY-FORWARD contenant une option RSSO enregistre les options classées RSOO fournies par le relais DHCPv6. Il peut ensuite transmettre ces informations aux clients en ajoutant les options de classe RSOO qu’il accepte de transmettre au client.  
−
+
−
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @::1 -x 2001:db8:330f:a0d1::217
+
−
; (1 server found)
+
−
;; global options: +cmd
+
−
;; Got answer:
+
−
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65205
+
−
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 7
+
−
+
−
;; 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
+
−
+
−
;; Query time: 0 msec
+
−
;; SERVER: ::1#53(::1)
+
−
;; WHEN: Tue Mar 17 11:31:56 2015
+
−
;; MSG SIZE rcvd: 356
+
  
−
====Exemple d’interrogation d’un serveur DNS avec la commande ''host'' : résolution inverse====
+
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.
  
−
root@r-13-v6:/var/bind# host -t aaaa s-13-v6
+
Un relais DHCPv6 n’a pas le droit de modifier le contenu d’une réponse (REPLY) destinée à un client.  
−
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.
+
  
−
==Recommandations opérationnelles pour l'intégration d'IPv6 ==
+
La structure de cette option est la suivante :
  
−
Le DNS, comme cela a été décrit dans l'introduction de ce chapitre, est à la fois une application TCP/IP et une infrastructure critique. C'est l’application TCP/IP client-serveur qui gère la base de données distribuée à la plus grande échelle qui soit. C'est une application critique parce qu’elle permet à toutes les autres applications TCP/IP classiques (web, mail, ftp...) de fonctionner.
+
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    ...
 +
+-+-+-+-+-+-+-+-+-+-+-+
  
−
L'intégration progressive d'IPv6 entraîne de nouveaux problèmes opérationnels liés au DNS. Ces problèmes sont dus à la fragmentation de l’espace de nommage. Il convient donc soit de les éviter, soit de trouver les solutions adéquates pour y remédier. À cet effet, les RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. 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 <ref>Evans R. (2015).  [https://medium.com/ Medium] [https://medium.com/@rvedotrc/on-dns-and-ipv6-9d0638091e67 On DNS and IPv6]</ref>.
+
Pour en savoir plus, consulter le RFC 6422.
  
−
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.
+
==Codes d’état du protocole DHCPv6 ==
  
−
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.  
+
Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 8415.
 +
Name        Code Description
 +
----------  ---- -----------
 +
Success        0 Success.
 +
UnspecFail      1 Failure, reason unspecified; this
 +
                  status code is sent by either a client
 +
                  or a server to indicate a failure
 +
                  not explicitly specified in this
 +
                  document.
 +
NoAddrsAvail    2 Server has no addresses available to assign to
 +
                  the IA(s).
 +
NoBinding      3 Client record (binding) unavailable.
 +
NotOnLink      4 The prefix for the address is not appropriate for
 +
                  the link to which the client is attached.
 +
UseMulticast    5 Sent by a server to a client to force the
 +
                  client to send messages to the server.
 +
                  using the All_DHCPV6_Relay_Agents_and_Servers
 +
                  address.
  
−
=== Deux impossibilités d’accéder au service de nommage et leurs remèdes ===
+
==Structure des identifiants DUID du protocole DHCPv6 ==
  
−
Cette partie présente deux scénarios où l’accès au DNS est impossible et les remèdes qui permettent d’éviter ces situations. Avant IPv6, le processus de résolution DNS ne faisait intervenir qu’IPv4. Le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver confronté à des cas où l'espace de nommage est fragmenté. Dans ce cas, certains fragments de cet espace ne sont accessibles que via IPv4, et d'autres ne sont accessibles que via IPv6. Voici, par exemple, deux scénarios illustrant ce problème de fragmentation de l’espace d’adressage ainsi que la solution recommandée par l’IETF dans chaque scénario : client IPv4 et serveur IPv6, client IPv6 et serveur IPv4.
+
=== DUID construit à partir de l'adresse physique + horodate (DUID-LLT) ===
  
−
====Premier scénario : client IPv4 et serveur IPv6 ====
+
<center>
 +
[[Image:MOOC_dhcp_Fig3.png|400px|center|thumb|Figure 1 : Format du DUID-LLT.]]
 +
</center>
 +
 +
<tt>Msg-type</tt> : le champ <tt>type</tt> (2 octets) vaut 1.
  
−
Un client ne supportant qu'IPv4 envoie une requête relative à une zone hébergée sur des serveurs DNS ne supportant qu'IPv6. Dans ce cas, le processus de résolution échoue du fait de l'impossibilité d'accéder aux serveurs DNS officiels de cette zone. La recommandation est de faire en sorte que toute zone soit servie par au moins un serveur DNS officiel qui supporte IPv4. Ceci remédie à ce problème.  
+
<tt>Hardware type</tt> : deux octets contiennent le type de réseau physique.
  
−
====Second scénario : client IPv6 et serveur IPv4 ====
+
<tt>Time</tt> : l’horodate est codée sur 4 octets.
  
−
Un client ne supportant qu'IPv6 envoie une requête relative à une zone hébergée sur des serveurs DNS ne supportant qu'IPv4. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer du fait de l’impossibilité pour ce serveur DNS récursif de joindre, pour la zone concernée, des serveurs DNS officiels supportant IPv6. La recommandation est de configurer le serveur récursif en le faisant pointer vers un relais DNS fonctionnant en double pile IPv4/IPv6. Ceci remédie à ce problème.  
+
<tt>Link-layer address</tt> : la longueur de l’adresse physique (adresse MAC) varie en fonction du type du réseau physique.  
  
−
Par exemple, pour une distribution BIND, il suffit d'ajouter l'option : ''forwarders {<liste des adresses des serveurs forwarders> ;}'' dans le fichier ''named.conf.options''.
+
Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer.
 +
 +
Ce type de DUID est recommandé pour les ordinateurs de bureau, les ordinateurs portables, ou plus généralement pour tout équipement doté d'une mémoire non volatile où l’écriture est possible.
  
−
===Taille limitée des messages DNS en UDP, extension EDNS.0 ===
+
=== DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN) ===
  
−
Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF : RFC 1034 et RFC 1035. De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements AAAA, SRV, extensions DNSSEC...).  
+
Un constructeur affecte ce type d’identificateur à un équipement. Le DUID-EN combine le numéro unique affecté à l’entreprise et un identificateur de longueur variable, unique pour l’entreprise et défini par elle. Le numéro d’entreprise est généralement un entier non signé codé sur 32 bits. La figure 2 présente la structure de l'option.  
  
−
Le DNS, en tant qu'application TCP/IP, doit supporter les deux modes de transport UDP et TCP (RFC 1035). Le port associé à l’application DNS est le même pour TCP et pour UDP : 53. Le protocole de transport UDP est généralement utilisé pour acheminer les requêtes/réponses DNS. Le protocole de transport TCP est généralement utilisé pour les transferts de zones entre serveur DNS primaire et secondaires.  
+
<center>
 +
[[Image:MOOC_dhcp_Fig4.png|400px|center|thumb|Figure 2 : Format du DUID-EN.]]
 +
</center>
 +
 +
Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction et l’enregistre dans une mémoire non volatile de l’équipement.
  
−
Lorsque le DNS utilise le protocole de transport UDP, la taille des messages DNS est limitée à 512 octets. Certaines requêtes, trop grandes pour être acheminées par UDP, induisent un acheminement par TCP. Dans ce cas, le client reçoit, dans un premier temps, un message dont la section réponse (''answer section'') est vide et dont le bit TC (''TrunCated'') vaut 1. Ceci signifie implicitement que le client est invité à réinterroger le serveur en utilisant TCP. Notez que ce scénario justifie le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour des transferts de zones. Notez, par ailleurs, qu’un recours trop fréquent à TCP risque de consommer davantage de ressources, et par conséquent, de dégrader les performances du serveur DNS.
+
=== DUID dérivé de l’adresse physique de l’équipement (DUID-LL) ===
  
−
Certains nouveaux types d'enregistrements (AAAA) risquent d'augmenter significativement la taille des réponses DNS. Ceci risque donc d’accroître le nombre de recours à TCP pour satisfaire les requêtes/réponses DNS. Aujourd'hui, ces dépassements sont rares. La plupart des réponses DNS ont une taille qui ne dépasse guère 400 octets. En effet, les sections answer, authority et additional, qui constituent l’essentiel de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements lorsque cette réponse ne concerne pas directement une zone racine telle que ''.com, .net, .fr, .de''.
+
Le DUID-LL n’utilise que l’adresse physique de l’équipement. La longueur de l’adresse physique (adresse MAC) varie en fonction du réseau physique. Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer. La figure 3 présente la structure de l'option.
  
−
Face à ce risque, l’IETF a proposé l'extension EDNS.0 du protocole DNS (RFC 6891). Elle permet qu’un client DNS informe le serveur interrogé qu’il supporte des réponses de taille supérieure à la limite des 512 octets (par exemple, 4096 octets). Ainsi, le support de l’extension du DNS, 'EDNS.0', est fortement recommandé en présence d'IPv6. Cette extension est déjà déployée dans les versions récentes des logiciels DNS. Notez également que le support d'EDNS.0 est aussi indispensable en présence des extensions de sécurité de DNS, DNSSEC.  
+
<center>
 +
[[Image:MOOC_dhcp_Fig5.png|400px|center|thumb|Figure 3 : Format du DUID-LL.]]
 +
</center>
  
−
Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS, surtout les clients, est resté pendant plusieurs années un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs "racine". Depuis le 4 février 2008, l'IANA publie l'adresse IPv6 (enregistrement AAAA) des serveurs "racine" supportant le transport IPv6 dans la zone "racine". La nouvelle version du fichier de démarrage (''db.cache'') de BIND 9 contient également ces adresses. Notez enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : [[https://www.iana.org/domains/root/files]].
+
Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.
  
−
<!-- PUTODO-->
+
Ce format est recommandé pour les équipements dépourvus de mémoire de stockage et qui ont une interface de réseau connectée en permanence au réseau (une imprimante réseau, par exemple).
  
−
===Glue IPv6 ===
+
==Options pour la délégation de préfixes (RFC 8415) ==
  
−
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.
+
=== Structure de l'option d'association d'identités pour la délégation de préfixes  ===
  
−
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).
+
La figure 4 présente la structure de cette option.
−
<!-- PUTODO ici il ne s'agit pas des serveurs racines mais des serveurs qui gerent les TLD.-->
+
<center>
−
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…
+
[[Image:MOOC_dhcp_Fig11.png|400px|center|thumb|Figure 4 : Format de l'option d'association d'identités pour la délégation de préfixes.]]
 +
</center>
  
−
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. <!--PUTODO Pas certain d'avoir compris cette phrase -->
+
''OPTION_IA_PD'' : le champ <tt>type</tt> de cette option a pour valeur 25.  
−
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.
+
  
−
===Publication des enregistrements AAAA dans le DNS ===
+
''Option-length'' : la longueur de l'option est la longueur, en nombre d'octets, de la valeur des options IA_PD options.
  
−
On choisit généralement de publier dans le DNS les enregistrements AAAA d’un équipement donné lorsque l'on souhaite que les applications communiquant avec cet équipement découvrent qu’il supporte le transport IPv6. Par exemple, un navigateur supportant IPv6, découvre ainsi, grâce au DNS, qu'il est possible d’accéder en IPv6 au site http://www.afnic.fr/. Il peut alors choisir de privilégier la connexion HTTP au serveur en IPv4 ou en IPv6. Or, avec l'intégration progressive d'IPv6, l'adresse IPv6 d’un équipement peut être publiée dans le DNS. Malgré tout, certaines applications s'exécutant sur cet équipement peuvent cependant ne pas supporter IPv6.  
+
''IAID'' : c'est l'identificateur d'association d'identités.
 +
 +
''T1, T2'' : les temporisations T1 et T2 représentent, en secondes, les durées de vie du préfixe en mode préféré et durée de vie totale.
  
−
La situation suivante risque donc de se produire. L'équipement ''foo.tpt.example.com'' héberge plusieurs services : web, ftp, mail, DNS. Les serveurs Web et DNS s'exécutant sur ''foo.tpt.example.com'' supportent IPv6, mais pas les serveurs FTP et mail. Une adresse IPv6 est publiée dans le DNS pour ''foo.tpt.example.com''. Un client FTP supportant IPv6 tente d’accéder au serveur de notre équipement : ''foo.tpt.example.com''. Le client choisit l'adresse IPv6 associée à''foo.tpt.example.com'' comme adresse destination. Sa tentative d’accès au serveur FTP en IPv6 échoue. Selon les implémentations, les clients tentent ou non d’utiliser d'autres adresses IPv6, s'il y en a, et finissent ou non par tenter d’y accéder, en dernier recours, en IPv4.
+
=== Option de préfixe d'association d'identités pour la délégation de préfixe ===
 +
L'option de préfixe d'association d'identités pour la délégation de préfixe (IA_PD Prefix) contient les préfixes associés à une IA_PD. Elle est incluse dans l'option IA_PD. La figure 5 présente la structure de cette option.
  
−
Notez que, pour pallier ce problème, l’IETF recommande d'associer des noms DNS aux services et non aux équipements. Ainsi, pour notre exemple précédent, il serait judicieux de publier dans le DNS, d'une part, les noms ''www.tpt.example.com ''et ''ns.tpt.example.com ''associés à des adresses IPv6, et éventuellement, des adresses IPv4, et d'autre part, les noms ''ftp.tpt.example.com'' et ''mail.tpt.example.com'' associés uniquement à des adresses IPv4.
+
<center>
−
 
+
[[Image:MOOC_dhcp_Fig12_1.png|400px|center|thumb|Figure 5 : Format de l'option de préfixe d'associations d'identités pour la délégation de préfixe.]]
−
L'enregistrement AAAA pour ''foo.tpt.example.com'' ne serait alors publié que lorsque l'on aurait la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6. Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il fait !) d'y publier des adresses IPv6 non accessibles depuis l'extérieur, soit à cause d'une portée trop faible (adresse locale au lien, par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notez que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS. On parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''. Les vues permettent d’exécuter plusieurs serveurs virtuels sur une même machine. Elles permettent que la réponse à une requête DNS dépende de la localisation du client. Par exemple, un client du réseau interne voit les adresses privées des équipements alors que les clients externes ne voient eux que les adresses globales et accessibles depuis l'extérieur.
+
</center>
−
 
+
−
===Pour aller plus loin : mises à jour dynamiques du DNS===
+
−
 
+
−
Le système de noms de domaines a été initialement conçu pour interroger une base de données statique. Les données pouvaient changer, mais leur fréquence de modification devait rester faible. Toutes les mises à jour se faisaient en éditant les fichiers de zone maîtres (du serveur DNS primaire).
+
−
 
+
−
L’opération de mise à jour, UPDATE, permet l’ajout ou la suppression de RR ou d’ensembles de RR dans une zone spécifiée, lorsque certains prérequis sont satisfaits. Cette mise à jour est possible depuis un serveur DHCPv6, par exemple, ou depuis une machine IPv6 (autoconfiguration "sans état"). La mise à jour est atomique, c'est-à-dire qu'elle sera effectuée intégralement avant qu'une autre opération soit effectuée et tous les prérequis doivent au préalable être satisfaits pour que la mise à jour soit possible et qu'elle ait lieu. Aucune condition d’erreur relative aux données ne peut être définie après que les prérequis soient satisfaits. Les prérequis concernent un ensemble de RR ou un seul RR. Ceux-ci peuvent ou non exister. Ils sont spécifiés séparément des opérations de mise à jour.
+
−
 
+
−
La mise à jour s’effectue toujours sur le serveur DNS primaire de la zone concernée. Si un client s’adresse à un serveur DNS secondaire, ce dernier relaie la demande de mise à jour vers le serveur DNS primaire (''update forwarding''). Le serveur DNS primaire incrémente le numéro de version de l’enregistrement SOA de la zone concernée, soit après un certain nombre de mises à jour, par exemple 100, soit à l’expiration d’un certain délai, par exemple 5 minutes, en fonction 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.  
+
<tt>Msg-type</tt> : le champ <tt>type</tt> de cette option vaut 26.
  
−
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.
+
<tt>Option-length</tt> : le champ <tt>longueur</tt> du champ <tt>option</tt> est la longueur en nombre d'octets du champ <tt>option</tt> de cette option.
  
−
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.
+
<tt>Preferred-lifetime, valid lifetime</tt> : les durées de vie préférée et totale sont celles du préfixe.  
  
−
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''.
+
<tt>Prefix-length</tt> : ce champ donne la longueur en bits du préfixe.
  
−
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.  
+
<tt>IPv6 prefix</tt> : la valeur du préfixe, codée sur 16 octets, donne la valeur du préfixe.
  
−
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.
+
<tt>IAprefix-options</tt> : liste les options relatives à ce préfixe.

Latest revision as of 16:25, 6 June 2019



ANNEXE 3 Activité 34 : Format DHCPv6

Structure des options du protocole DHCPv6

La structure générale des options est décrite ci-dessous. Elle correspond à un codage TLV : type, longueur, valeur.

Le type ou code est un entier non signé. Il précise quelle est l’option. La longueur de l’option précise la taille en nombre d'octets du champs de données de l’option. Le champ type de l'option en est exclu. Les données de l’option suivent. Dans certains cas, une option peut en contenir d’autres.

La portée des options est définie par encapsulation. Certaines options s'appliquent globalement, d'autres sont spécifiques d'une association d'identités, d'autres encore sont spécifiques d'une adresse, dans une association d'identités.

La structure générale d'une option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         option-code           |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         option-data                           |
|                    (option-len octets)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Option d'identification du client

L'option d'identification du client (Client Identifier Option) transporte le DUID (DHCPv6 User Identification) du client dans les messages DHCPv6 échangés entre client et serveur.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         OPTION_CLIENTID       |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                             DUID                              .
.                          (variable length                     .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option identification du serveur (Server Identification Option)

L'option "identification du serveur" (Server Identification Option) transporte le DUID (DHCPv6 User Identification) du serveur dans les messages DHCPv6 échangés entre client et serveur.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID                | option-len                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                               DUID                            .
.                         (variable length)                     .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option association d’identité pour les adresses non temporaires

L'option "association d’identité" pour les adresses non temporaires (option IA_NA : Identity Association for Non Temporary Addresses) inclut les paramètres de cette association et les adresses non temporaires associées. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6.

Cette association transporte un identificateur d'IA_NA, les temporisations T1, durée de vie préférée d'une adresse, et T2, durée de vie maximum d'une adresse, et les options de cette association, par exemple la liste des options d'adresse spécifiques de cette association.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            OPTION_IA_NA       |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IAID (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              T1                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              T2                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                          IA_NA-options                        .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option d'association d’identité pour les adresses temporaires

L'option d'association d’identité pour les adresses temporaires (option IA_TA : Identity Association for Temporary Addresses) inclut les paramètres de cette association et au plus une adresse temporaire associée par préfixe autorisé sur le lien du client. Elle apparaît une ou plusieurs fois dans le champ d'options d'un message DHCPv6. Une option statut indique l'état de toute opération impliquant cette option.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            OPTION_IA_TA       |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IAID (4 octets)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                         IA_TA-options                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option d’adresse d'association d'identités

L'option d'adresse d'association d'identités (IA Address Option) spécifie une adresse IPv6 associée à une association d'identités IA_NA ou IA_TA. Elle apparaît dans le champ d'option d'une association d'identités pour adresse non temporaire ou temporaire. Une option statut indique l'état de toute opération impliquant cette adresse.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          OPTION_IAADDR        |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         IPv6 address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     preferred-lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       valid-lifetime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                       IAaddr-options                          .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option de demande d’options

L'option de demande d'option (Options Request Option) identifie la liste des options demandées par le client ou fournies ou concernées pour le serveur.

La structure de cette option est la suivante : 

  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           OPTION_ORO          |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    requested-option-code-1    |    requested-option-code-2    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option de priorité (du serveur)

L'option de priorité (Preference Option) indique la priorité du serveur au client.

Un client choisit le serveur de priorité la plus élevée. En cas d'égalité des priorités, il choisit le serveur de priorité la plus élevée qui lui propose la meilleure offre. Il peut ne pas choisir l'offre du serveur le plus prioritaire. Le choix repose alors sur l'adéquation de l'offre.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION_PREFERENCE      |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   pref-value  |
+-+-+-+-+-+-+-+-+

Option "temps écoulé" (depuis le début d'un échange)

L'option "temps écoulé" mesure le temps écoulé (Elapsed Time Option) depuis l'émission du premier message d'un échange DHCPv6 inachevé. Cette option vaut 0 dans le premier message d'un échange.

Serveurs et agents utilisent la valeur de cette option pour déterminer leur façon de traiter le message DHCPv6 correspondant. La valeur ffff en hexadécimal (0xffff) représente une durée supérieure à la plus grande durée représentable.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_ELAPSED_TIME     |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         elapsed-time          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option "message relayé"

L'option "message relayé" (RELAY Message Option) contient le message DHCPv6 relayé dans un message RELAY-FORWARD ou RELAY-REPLY.

Le message relayé, dans le cas d'un message qui transite du client vers le serveur, est soit le message DHCPv6 du client (premier relais), soit le message RELAY-FORWARD du relais précédent (du deuxième relais au dernier).

Le message relayé dans le cas d'un message qui transite du serveur vers le client est, soit le message REPLY du serveur (premier relais), soit le message RELAY-REPLY du relais précédent (du deuxième relais au dernier).

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_RELAY_MSG        |            option-len         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                       DHCP-relay-message                      .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option d’authentification

L'option d'authentification (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 d’utilisation de l'adresse individuelle du serveur

L'option d'utilisation de l'adresse individuelle du serveur (Server Unicast Option) qu'envoie un serveur, autorise le client DHCPv6 qui reçoit cette option à échanger avec le serveur en utilisant son adresse individuelle au lieu de l'adresse de diffusion sélective All_DHCP_Relay_Agents_and_Servers address.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           OPTION_UNICAST      |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       server-address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option de code d’état

L'option code d'état (Status Code Option) renvoie une indication d'état relative au message DHCPv6 ou à l'option dans laquelle cette option apparaît. L'omission du code d'état dans un message ou dans une option où son utilisation est possible signifie "succès".

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      OPTION_STATUS_CODE       |            option-len         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        status-code            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
.                                                               .
.                        status-message                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'annexe 2 présente les valeurs des différents codes d'état.

Option de Validation rapide

L'option de validation rapide (Rapid Commit Option) indique l'utilisation d'un échange à deux messages pour l'allocation d'adresses IPv6. Le principe de cette allocation est le suivant :

(1) Un client, prêt à utiliser la validation rapide peut inclure cette option dans son message SOLICIT.

(2) Un serveur doit inclure cette option dans le message REPLY qui répond au SOLICIT du client transportant l'option de validation rapide.

La structure de cette option est la suivante : 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_RAPID_COMMIT     |               0               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option classe d'utilisateur

L'option classe d'utilisateur (User Class Option) identifie un type ou une classe d'utilisateurs ou d'applications qu'ils représentent. La partie données de cette option contient plusieurs champs non interprétés (opaque) par DHCPV6. Ces champs représentent la classe d'utilisateur à laquelle appartient le client.

Un serveur choisit les informations de configuration du client en fonction de la classe identifiée par l'option.

La structure de cette option est la suivante : 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         OPTION_USER_CLASS     |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         user-class-data                       .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La structure de la partie "données" de cette option peut apparaître plusieurs fois. Elle est la suivante : 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
|       user-class-len          |           opaque-data         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

Option de classe de constructeur

L'option de classe de constructeur (Vendor Class Option) identifie le constructeur du matériel qui supporte le client DHCPv6. Le numéro d'entreprise identifie le constructeur.

La structure de cette option est la suivante : 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      OPTION_VENDOR_CLASS      |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       enterprise-number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                       vendor-class-data                       .
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les paramètres définissant la classe du constructeur se suivent les uns les autres dans le champ de données de classe de constructeur. Chaque paramètre est codé en format LV. DHCPv6 n'interprète pas la valeur (opaque) de ces paramètres. 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
|         vendor-class-len      |      opaque-data              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

Option d'information spécifique d'un constructeur

L'option d'information spécifique d'un constructeur (Vendor-specific Information Option) permet que les clients et serveurs DHCPv6 échangent des informations spécifiques d'un constructeur. Le numéro d'entreprise identifie le constructeur.

La structure de cette option est la suivante : 

 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_VENDOR_OPTS       |            option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       enterprise-number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         option-data                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La spécification des données échangées dépend du constructeur. Chacune de ces options de données est codée en format TLV. Le constructeur définit leur code. Plusieurs options de données peuvent se succéder dans le champ de données de l'option d'information spécifique d'un constructeur.

La structure de l'option de donnée spécifique d'un constructeur est la suivante : 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            opt-code          |            option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                          option-data                          .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option d'identification d'interface

L'option d'identification d'interface (Interface-Id Option) identifie, sur un relais, l'interface de réception du message d'un client.

Un relais qui reçoit un message incluant une option d'identification d'interface relaie le message reçu sur l'interface identifiée dans l'option.

Les serveurs qui reçoivent cette option dans un message RELAY-FORWARD doivent la recopier dans leur message RELAY-REPLY. cette option est spécifique des messages RELAY-FORWARD et RELAY-REPLY. Ils peuvent également utiliser cette information pour appliquer une politique d'allocation basée sur la correspondance exacte de la valeur de cette option.

La structure de cette option est la suivante : 

   0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     OPTION_INTERFACE_ID       |            option-len         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                        interface-id                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option de message de reconfiguration

L'option de message de reconfiguration (Reconfigure Message Option), présente dans un message de reconfiguration issue d'un serveur, indique au client s'il doit répondre à l'aide d'un message RENEW ou INFORMATION-REQUEST. Cette option est spécifique du message de reconfiguration.

La structure de cette option est la suivante : 

 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_RECONF_MSG       |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    msg-type   |
+-+-+-+-+-+-+-+-+

Option d'acceptation de reconfiguration

L'option d'acceptation de reconfiguration (Reconfigure Accept Option) annonce au serveur que le client accepte les messages de reconfiguration.

Un serveur utilise cette option pour dire au client s'il doit ou non accepter les messages de reconfiguration. L'absence de cette option indique le refus d'accepter des messages de reconfiguration. La présence de cette option indique au client s'il doit ou non accepter les messages de reconfiguration.

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_RECONF_ACCEPT     |                0              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extension du protocole DHCPv6 : options spécifiques des relais

Dans certains cas, les relais DHCPv6 connaissent des informations qui seraient utiles aux clients DHCPv6.

Le protocole DHCPv6 est étendu (RFC 6422) pour que les relais puissent inclure une option RSSO : RELAY-SUPPLIED OPTIONS OPTION dans les messages RELAY-FORW adressés au serveur DHCPv6.

L'option d'options spécifiques de relais (RELAY-SUPPLIED OPTIONS OPTION) dans les messages RELAY-FORWARD adressés au serveur DHCPv6 contient alors toutes les options correspondant à des paramètres que le relais souhaite porter à la connaissance du client. Cette possibilité n’est effective que pour des paramètres classés RSOO.

Le serveur DHCPv6 qui reçoit un message RELAY-FORWARD contenant une option RSSO enregistre les options classées RSOO fournies par le relais DHCPv6. Il peut ensuite transmettre ces informations aux clients en ajoutant les options de classe RSOO qu’il accepte de transmettre au client.

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

Pour en savoir plus, consulter le RFC 6422.

Codes d’état du protocole DHCPv6

Cette annexe présente les codes d’état du protocole DHCPv6. Ils sont extraits du RFC 8415. 

Name         Code Description 
----------   ---- -----------
Success         0 Success.
UnspecFail      1 Failure, reason unspecified; this
                  status code is sent by either a client
                  or a server to indicate a failure
                  not explicitly specified in this
                  document.
NoAddrsAvail    2 Server has no addresses available to assign to
                  the IA(s).
NoBinding       3 Client record (binding) unavailable.
NotOnLink       4 The prefix for the address is not appropriate for
                  the link to which the client is attached.
UseMulticast    5 Sent by a server to a client to force the
                  client to send messages to the server.
                  using the All_DHCPV6_Relay_Agents_and_Servers
                  address.

Structure des identifiants DUID du protocole DHCPv6

DUID construit à partir de l'adresse physique + horodate (DUID-LLT)

Figure 1 : Format du DUID-LLT.

Msg-type : le champ type (2 octets) vaut 1.

Hardware type : deux octets contiennent le type de réseau physique.

Time : l’horodate est codée sur 4 octets.

Link-layer address : la longueur de l’adresse physique (adresse MAC) varie en fonction du type du réseau physique.

Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer.

Ce type de DUID est recommandé pour les ordinateurs de bureau, les ordinateurs portables, ou plus généralement pour tout équipement doté d'une mémoire non volatile où l’écriture est possible.

DUID dérivé du numéro d’entreprise affecté par un constructeur (DUID-EN)

Un constructeur affecte ce type d’identificateur à un équipement. Le DUID-EN combine le numéro unique affecté à l’entreprise et un identificateur de longueur variable, unique pour l’entreprise et défini par elle. Le numéro d’entreprise est généralement un entier non signé codé sur 32 bits. La figure 2 présente la structure de l'option.

Figure 2 : Format du DUID-EN.

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction et l’enregistre dans une mémoire non volatile de l’équipement.

DUID dérivé de l’adresse physique de l’équipement (DUID-LL)

Le DUID-LL n’utilise que l’adresse physique de l’équipement. La longueur de l’adresse physique (adresse MAC) varie en fonction du réseau physique. Le choix de l’interface dont on utilise l’adresse physique est indifférent tant que l’identification est unique. Le DUID doit être enregistré dans une mémoire non volatile et doit continuer à être utilisé, même en cas de remplacement ultérieur de l’interface qui a servi à le générer. La figure 3 présente la structure de l'option.

Figure 3 : Format du DUID-LL.

Le constructeur affecte généralement cet identificateur unique à l’équipement lors de sa construction. Il l’enregistre généralement dans une mémoire non volatile de l’équipement.

Ce format est recommandé pour les équipements dépourvus de mémoire de stockage et qui ont une interface de réseau connectée en permanence au réseau (une imprimante réseau, par exemple).

Options pour la délégation de préfixes (RFC 8415)

Structure de l'option d'association d'identités pour la délégation de préfixes

La figure 4 présente la structure de cette option.

Figure 4 : Format de l'option d'association d'identités pour la délégation de préfixes.

OPTION_IA_PD : le champ type de cette option a pour valeur 25.

Option-length : la longueur de l'option est la longueur, en nombre d'octets, de la valeur des options IA_PD options.

IAID : c'est l'identificateur d'association d'identités.

T1, T2 : les temporisations T1 et T2 représentent, en secondes, les durées de vie du préfixe en mode préféré et durée de vie totale.

Option de préfixe d'association d'identités pour la délégation de préfixe

L'option de préfixe d'association d'identités pour la délégation de préfixe (IA_PD Prefix) contient les préfixes associés à une IA_PD. Elle est incluse dans l'option IA_PD. La figure 5 présente la structure de cette option.

Figure 5 : Format de l'option de préfixe d'associations d'identités pour la délégation de préfixe.

Msg-type : le champ type de cette option vaut 26.

Option-length : le champ longueur du champ option est la longueur en nombre d'octets du champ option de cette option.

Preferred-lifetime, valid lifetime : les durées de vie préférée et totale sont celles du préfixe.

Prefix-length : ce champ donne la longueur en bits du préfixe.

IPv6 prefix : la valeur du préfixe, codée sur 16 octets, donne la valeur du préfixe.

IAprefix-options : liste les options relatives à ce préfixe.

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Annexe_Compagnon_Act34&oldid=16104"
Personal tools