Livre IPv6 - User contributions [en]

MOOC:Conclusion-d

2015-10-01T07:57:30Z

Nbenamar:

Idées:

* IPv4 a été une première expérience pour l’élaboration d’IPv6
* IPv6 source d'innovation et de création de valeur dans l'économie du numérique
* IPv6 = catalyseur de l'innovation numérique
* Abondance des adresses IPv6 : catalyseur d'innovation
* IPv6: des opportunités d'occuper une position stratégique sur les nouveaux marchéx se restreignent

* Le déploiement d'IPv6 une nécessite.
- IPv6 pour la continuité d'Internet
- Intégrer IPv6 a votre réseau IPv4

==Remerciements==

Les auteurs souhaitent remercier Stéphane Bortzmeyer pour ses analyses de RFC sur IPv6 (http://www.bortzmeyer.org/) dont des extraits ont été utilisés pour ce cours.

MOOC:Compagnon Act34-s6

2015-06-07T13:20:29Z

Nbenamar: /* Fichier de configuration d'un serveur BIND9 */

= Le système de nommage en IPv6 =
== Introduction ==

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier <tt>hosts.txt</tt> (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence <tt>/etc/hosts</tt> pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983, et a écrit la première mise en œuvre à la demande de Jon Postel. Le DNS permet de résoudre un nom de domaine, un mécanisme qui consiste à trouver l'adresse IP qui lui est associée.

Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

* hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
* réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
* et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

== Spécifications ==

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully Qualified Domain Name'') garantissant l'unicité du nom (exemple : <tt>ns3.nic.fr</tt>) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : ''Resource Records'') et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type <tt>MX</tt>) ou les serveurs de noms (enregistrement de type <tt>NS</tt>).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier <tt>/etc/resolv.conf</tt> fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

* l'enregistrement <tt>AAAA</tt> (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
* le nouveau sous-arbre DNS inverse <tt>ip6.arpa</tt> pour le nommage inverse (correspondance : adresse vers nom)

=== Nommage direct : enregistrement AAAA ===

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement <tt>AAAA</tt> défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements <tt>AAAA</tt> publiés dans le DNS. Une requête DNS de type <tt>AAAA</tt> concernant une machine particulière retourne dans ce cas tous les enregistrements <tt>AAAA</tt> publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe [[NommageBis#3.4.5._Publication_des_enregistrements_AAAA_dans_le_DNS|Publication des enregistrements AAAA dans le DNS]]. {{ToDo|envoyer vers la bonne référence}}

Le format textuel d'un enregistrement <tt>AAAA</tt> tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine <tt>ns3.nic.fr</tt> est publiée dans le fichier de zone <tt>nic.fr</tt> comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné (c'est le cas d'un réseau configuré en dual-stack), doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de <tt>ns3.nic.fr</tt> sont publiées dans le fichier de zone <tt>nic.fr</tt> comme suit :

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

Cependant, il faut rester vigilant avec une telle configuration, puisque certains resolvers vont toujours rechercher un enregistrement AAAA avant l'enregistrement A, même si l'hôte executant le resolver n'a qu'une connection IPv6 limitée (une simple adresse lien local!).
Dans ce cas de figure, l'hôte va attendre le time-out de la connection IPv6 avant de switcher vers IPv4 !!

=== Nommage inverse : enregistrement PTR ===

L'enregistrement de type <tt>PTR</tt>, stocké sous l'arbre DNS inverse <tt>in-addr.arpa</tt>, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement <tt>PTR</tt>, qui, stocké sous l'arbre DNS inverse <tt>ip6.arpa</tt>, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : <tt>ip6.int</tt>. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse <tt>ip6.arpa</tt> de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `<tt>.</tt>' et concaténés dans l'ordre inverse au suffixe <tt>ip6.arpa</tt>.

Par exemple l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de <tt>ns3.nic.fr</tt>) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement <tt>PTR</tt> correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `<tt>ns3.nic.fr.</tt>'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements <tt>PTR</tt> sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

* 1) L'[http://www.iana.org/ IANA] délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
* 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions [http://www.apnic.net/ APNIC] et [http://www.lacnic.net/ LACNIC], il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
* 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

[[image:Fig6-1.png|thumb|right|400px|Figure 6-1 ''Exemple de délégation de zones inverse'']]

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse <tt>0.6.6.0.1.0.0.2.ip6.arpa</tt> de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe <tt>2001:660:3006::/48</tt> et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

== Mises en oeuvre ==

''Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''

=== Logiciels DNS supportant IPv6 ===

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements <tt>AAAA</tt> et <tt>PTR</tt>) et au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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 celle du serveur. Par exemple, la [http://www.isc.org/software/bind distribution BIND 9] développée par l'[http://www.isc.org ISC] (''Internet Systems Consortium'') représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons que les logiciels DNS développés par les [http://www.nlnetlabs.nl NLnetLabs] sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS faisant autorité (sans récursion) et [http://unbound.net/ Unbound] comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :
* pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
* pour la diversification de leur plates-formes logicielles (on parle souvent de ''diversité génétique'').

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

=== Clients et outils de vérification de configurations DNS ===

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

==== Exemples d'interrogation ====

Les six exemples suivants illustrent l'utilisation des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> pour la même requête de résolution du nom `<tt>ns3.nic.fr</tt>' en adresse(s) IPv6 :

>'''dig ns3.nic.fr aaaa'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

>'''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:

[...]

;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

>'''host -t aaaa ns3.nic.fr'''
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''host -t aaaa ns3.nic.fr ns-sec.ripe.net'''
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53
Aliases:

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''nslookup -type=aaaa ns3.nic.fr'''
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53

Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

[...]

>'''nslookup -type=aaaa ns3.nic.fr -secripe.net'''
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (<tt>2001:660:3003:2::1:1</tt>). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur <tt>ns-sec.ripe.net</tt> (qui est secondaire pour la zone <tt>nic.fr</tt>).

Notons que l'outil <tt>nslookup</tt> n'est plus maintenu par l'[http://www.isc.org/ ISC] et qu'il est amené à disparaître. L'usage de l'outil <tt>dig</tt> ou de <tt>host</tt> pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de <tt>ZoneCheck</tt>, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, [http://www.zonecheck.fr/ ZoneCheck] permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

=== Configuration de serveur/zone DNS ===

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

==== Fichier de configuration d'un serveur BIND9 ====

Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> :

options {
directory "/usr/local/bind";
recursion no;
listen-on { any;};
listen-on-v6 {any; };
[...]
};

[...]

zone "." {
type hint;
file "named.root";
};

zone "localhost" {
type master;
file "localhost";
};

// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};

// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour
// l'adresse loopback en IPv6

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.rev";
};

[...]

zone "nic.fr" {
type slave;
file "zone/nic.fr";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24

zone "0.134.192.in-addr.arpa" {
type slave;
file "rev/nic.fr.192.134.0";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Blocs Ripe sous ip6.arpa.

zone "6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.1.0.0.2.ip6.arpa";
masters {
2001:610:240:0:53::3;
193.0.0.195;
};
};

[...]

// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48

zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

L'option « <tt>listen-on</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

Par défaut, le serveur de nom BIND 9 ne va pas écouter les requêtes qui arrivent sur une interface IPv6. Pour changer ce comportement par défaut, on va utiliser l'option listen-on-v6

L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut).

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur <tt>ns3.nic.fr</tt> fait autorité.

====Fichier de zone DNS direct ====

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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épendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007102200 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1 IN A 192.93.0.1
IN AAAA 2001:660:3005:1::1:1
ns2 IN A 192.93.0.4
IN AAAA 2001:660:3005:1::1:2
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1

[...]

www IN CNAME rigolo
rigolo IN A 192.134.4.20
IN AAAA 2001:660:3003:2::4:20

kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98

[...]

====. Fichier de zone DNS inverse en IPv6 ====

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 <tt>2001:660:3003::/48</tt> (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007031200 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 );
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

== Recommandations opérationnelles pour l'intégration d'IPv6 ==

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

=== Les deux aspects du DNS ===

En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

=== Continuité du service DNS ===

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

* premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
* second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « <tt>options</tt> » dans le fichier <tt>named.conf</tt>.

=== Taille limitée des messages DNS en UDP ===

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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 <tt>TC</tt> (''Truncated'') est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.

Notons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : http://www.root-servers.org/ .

=== Glue IPv6 ===

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.

=== Publication des enregistrements AAAA dans le DNS ===

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

* l'équipement <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;
* les serveurs web et dns s'exécutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;
* une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
* un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;
* la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.

=== Enregistrement par les clients ===

{{TODO|Parler du DNS Dynamic Update pour les adresses IPv6 auto-configurées}}

MOOC:Compagnon Act34-s6

2015-06-06T18:20:39Z

Nbenamar: /* Nommage direct : enregistrement AAAA */

= Le système de nommage en IPv6 =
== Introduction ==

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier <tt>hosts.txt</tt> (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence <tt>/etc/hosts</tt> pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983, et a écrit la première mise en œuvre à la demande de Jon Postel. Le DNS permet de résoudre un nom de domaine, un mécanisme qui consiste à trouver l'adresse IP qui lui est associée.

Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

* hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
* réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
* et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

== Spécifications ==

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully Qualified Domain Name'') garantissant l'unicité du nom (exemple : <tt>ns3.nic.fr</tt>) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : ''Resource Records'') et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type <tt>MX</tt>) ou les serveurs de noms (enregistrement de type <tt>NS</tt>).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier <tt>/etc/resolv.conf</tt> fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

* l'enregistrement <tt>AAAA</tt> (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
* le nouveau sous-arbre DNS inverse <tt>ip6.arpa</tt> pour le nommage inverse (correspondance : adresse vers nom)

=== Nommage direct : enregistrement AAAA ===

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement <tt>AAAA</tt> défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements <tt>AAAA</tt> publiés dans le DNS. Une requête DNS de type <tt>AAAA</tt> concernant une machine particulière retourne dans ce cas tous les enregistrements <tt>AAAA</tt> publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe [[NommageBis#3.4.5._Publication_des_enregistrements_AAAA_dans_le_DNS|Publication des enregistrements AAAA dans le DNS]]. {{ToDo|envoyer vers la bonne référence}}

Le format textuel d'un enregistrement <tt>AAAA</tt> tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine <tt>ns3.nic.fr</tt> est publiée dans le fichier de zone <tt>nic.fr</tt> comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné (c'est le cas d'un réseau configuré en dual-stack), doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de <tt>ns3.nic.fr</tt> sont publiées dans le fichier de zone <tt>nic.fr</tt> comme suit :

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

Cependant, il faut rester vigilant avec une telle configuration, puisque certains resolvers vont toujours rechercher un enregistrement AAAA avant l'enregistrement A, même si l'hôte executant le resolver n'a qu'une connection IPv6 limitée (une simple adresse lien local!).
Dans ce cas de figure, l'hôte va attendre le time-out de la connection IPv6 avant de switcher vers IPv4 !!

=== Nommage inverse : enregistrement PTR ===

L'enregistrement de type <tt>PTR</tt>, stocké sous l'arbre DNS inverse <tt>in-addr.arpa</tt>, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement <tt>PTR</tt>, qui, stocké sous l'arbre DNS inverse <tt>ip6.arpa</tt>, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : <tt>ip6.int</tt>. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse <tt>ip6.arpa</tt> de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `<tt>.</tt>' et concaténés dans l'ordre inverse au suffixe <tt>ip6.arpa</tt>.

Par exemple l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de <tt>ns3.nic.fr</tt>) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement <tt>PTR</tt> correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `<tt>ns3.nic.fr.</tt>'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements <tt>PTR</tt> sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

* 1) L'[http://www.iana.org/ IANA] délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
* 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions [http://www.apnic.net/ APNIC] et [http://www.lacnic.net/ LACNIC], il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
* 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

[[image:Fig6-1.png|thumb|right|400px|Figure 6-1 ''Exemple de délégation de zones inverse'']]

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse <tt>0.6.6.0.1.0.0.2.ip6.arpa</tt> de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe <tt>2001:660:3006::/48</tt> et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

== Mises en oeuvre ==

''Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''

=== Logiciels DNS supportant IPv6 ===

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements <tt>AAAA</tt> et <tt>PTR</tt>) et au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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 celle du serveur. Par exemple, la [http://www.isc.org/software/bind distribution BIND 9] développée par l'[http://www.isc.org ISC] (''Internet Systems Consortium'') représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons que les logiciels DNS développés par les [http://www.nlnetlabs.nl NLnetLabs] sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS faisant autorité (sans récursion) et [http://unbound.net/ Unbound] comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :
* pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
* pour la diversification de leur plates-formes logicielles (on parle souvent de ''diversité génétique'').

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

=== Clients et outils de vérification de configurations DNS ===

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

==== Exemples d'interrogation ====

Les six exemples suivants illustrent l'utilisation des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> pour la même requête de résolution du nom `<tt>ns3.nic.fr</tt>' en adresse(s) IPv6 :

>'''dig ns3.nic.fr aaaa'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

>'''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:

[...]

;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

>'''host -t aaaa ns3.nic.fr'''
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''host -t aaaa ns3.nic.fr ns-sec.ripe.net'''
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53
Aliases:

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''nslookup -type=aaaa ns3.nic.fr'''
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53

Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

[...]

>'''nslookup -type=aaaa ns3.nic.fr -secripe.net'''
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (<tt>2001:660:3003:2::1:1</tt>). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur <tt>ns-sec.ripe.net</tt> (qui est secondaire pour la zone <tt>nic.fr</tt>).

Notons que l'outil <tt>nslookup</tt> n'est plus maintenu par l'[http://www.isc.org/ ISC] et qu'il est amené à disparaître. L'usage de l'outil <tt>dig</tt> ou de <tt>host</tt> pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de <tt>ZoneCheck</tt>, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, [http://www.zonecheck.fr/ ZoneCheck] permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

=== Configuration de serveur/zone DNS ===

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

==== Fichier de configuration d'un serveur BIND9 ====

Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> :

options {
directory "/usr/local/bind";
recursion no;
listen-on { any;};
listen-on-v6 {any; };
[...]
};

[...]

zone "." {
type hint;
file "named.root";
};

zone "localhost" {
type master;
file "localhost";
};

// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};

// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour
// l'adresse loopback en IPv6

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.rev";
};

[...]

zone "nic.fr" {
type slave;
file "zone/nic.fr";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24

zone "0.134.192.in-addr.arpa" {
type slave;
file "rev/nic.fr.192.134.0";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Blocs Ripe sous ip6.arpa.

zone "6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.1.0.0.2.ip6.arpa";
masters {
2001:610:240:0:53::3;
193.0.0.195;
};
};

[...]

// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48

zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

L'option « <tt>listen-on</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut).

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur <tt>ns3.nic.fr</tt> fait autorité.

====Fichier de zone DNS direct ====

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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épendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007102200 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1 IN A 192.93.0.1
IN AAAA 2001:660:3005:1::1:1
ns2 IN A 192.93.0.4
IN AAAA 2001:660:3005:1::1:2
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1

[...]

www IN CNAME rigolo
rigolo IN A 192.134.4.20
IN AAAA 2001:660:3003:2::4:20

kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98

[...]

====. Fichier de zone DNS inverse en IPv6 ====

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 <tt>2001:660:3003::/48</tt> (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007031200 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 );
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

=== Recommandations opérationnelles pour l'intégration d'IPv6 ===

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

==== Les deux aspects du DNS ====

En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

==== Continuité du service DNS ====

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

* premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
* second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « <tt>options</tt> » dans le fichier <tt>named.conf</tt>.

==== Taille limitée des messages DNS en UDP ====

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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 <tt>TC</tt> (''Truncated'') est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.

Notons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : http://www.root-servers.org/ .

==== Glue IPv6 ====

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.

==== Publication des enregistrements AAAA dans le DNS ====

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

* l'équipement <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;
* les serveurs web et dns s'exécutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;
* une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
* un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;
* la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.

MOOC:Compagnon Act34-s6

2015-06-06T18:09:08Z

Nbenamar: /* Nommage direct : enregistrement AAAA */

= Le système de nommage en IPv6 =
== Introduction ==

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier <tt>hosts.txt</tt> (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence <tt>/etc/hosts</tt> pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983, et a écrit la première mise en œuvre à la demande de Jon Postel. Le DNS permet de résoudre un nom de domaine, un mécanisme qui consiste à trouver l'adresse IP qui lui est associée.

Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

* hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
* réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
* et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

== Spécifications ==

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully Qualified Domain Name'') garantissant l'unicité du nom (exemple : <tt>ns3.nic.fr</tt>) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : ''Resource Records'') et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type <tt>MX</tt>) ou les serveurs de noms (enregistrement de type <tt>NS</tt>).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier <tt>/etc/resolv.conf</tt> fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

* l'enregistrement <tt>AAAA</tt> (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
* le nouveau sous-arbre DNS inverse <tt>ip6.arpa</tt> pour le nommage inverse (correspondance : adresse vers nom)

=== Nommage direct : enregistrement AAAA ===

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement <tt>AAAA</tt> défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements <tt>AAAA</tt> publiés dans le DNS. Une requête DNS de type <tt>AAAA</tt> concernant une machine particulière retourne dans ce cas tous les enregistrements <tt>AAAA</tt> publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe [[NommageBis#3.4.5._Publication_des_enregistrements_AAAA_dans_le_DNS|Publication des enregistrements AAAA dans le DNS]]. {{ToDo|envoyer vers la bonne référence}}

Le format textuel d'un enregistrement <tt>AAAA</tt> tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine <tt>ns3.nic.fr</tt> est publiée dans le fichier de zone <tt>nic.fr</tt> comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné (c'est le cas d'un réseau configuré en dual-stack), doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de <tt>ns3.nic.fr</tt> sont publiées dans le fichier de zone <tt>nic.fr</tt> comme suit :

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

=== Nommage inverse : enregistrement PTR ===

L'enregistrement de type <tt>PTR</tt>, stocké sous l'arbre DNS inverse <tt>in-addr.arpa</tt>, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement <tt>PTR</tt>, qui, stocké sous l'arbre DNS inverse <tt>ip6.arpa</tt>, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : <tt>ip6.int</tt>. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse <tt>ip6.arpa</tt> de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `<tt>.</tt>' et concaténés dans l'ordre inverse au suffixe <tt>ip6.arpa</tt>.

Par exemple l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de <tt>ns3.nic.fr</tt>) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement <tt>PTR</tt> correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `<tt>ns3.nic.fr.</tt>'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements <tt>PTR</tt> sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

* 1) L'[http://www.iana.org/ IANA] délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
* 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions [http://www.apnic.net/ APNIC] et [http://www.lacnic.net/ LACNIC], il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
* 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

[[image:Fig6-1.png|thumb|right|400px|Figure 6-1 ''Exemple de délégation de zones inverse'']]

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse <tt>0.6.6.0.1.0.0.2.ip6.arpa</tt> de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe <tt>2001:660:3006::/48</tt> et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

== Mises en oeuvre ==

''Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''

=== Logiciels DNS supportant IPv6 ===

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements <tt>AAAA</tt> et <tt>PTR</tt>) et au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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 celle du serveur. Par exemple, la [http://www.isc.org/software/bind distribution BIND 9] développée par l'[http://www.isc.org ISC] (''Internet Systems Consortium'') représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons que les logiciels DNS développés par les [http://www.nlnetlabs.nl NLnetLabs] sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS faisant autorité (sans récursion) et [http://unbound.net/ Unbound] comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :
* pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
* pour la diversification de leur plates-formes logicielles (on parle souvent de ''diversité génétique'').

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

=== Clients et outils de vérification de configurations DNS ===

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

==== Exemples d'interrogation ====

Les six exemples suivants illustrent l'utilisation des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> pour la même requête de résolution du nom `<tt>ns3.nic.fr</tt>' en adresse(s) IPv6 :

>'''dig ns3.nic.fr aaaa'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

>'''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:

[...]

;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

>'''host -t aaaa ns3.nic.fr'''
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''host -t aaaa ns3.nic.fr ns-sec.ripe.net'''
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53
Aliases:

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''nslookup -type=aaaa ns3.nic.fr'''
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53

Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

[...]

>'''nslookup -type=aaaa ns3.nic.fr -secripe.net'''
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (<tt>2001:660:3003:2::1:1</tt>). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur <tt>ns-sec.ripe.net</tt> (qui est secondaire pour la zone <tt>nic.fr</tt>).

Notons que l'outil <tt>nslookup</tt> n'est plus maintenu par l'[http://www.isc.org/ ISC] et qu'il est amené à disparaître. L'usage de l'outil <tt>dig</tt> ou de <tt>host</tt> pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de <tt>ZoneCheck</tt>, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, [http://www.zonecheck.fr/ ZoneCheck] permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

=== Configuration de serveur/zone DNS ===

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

==== Fichier de configuration d'un serveur BIND9 ====

Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> :

options {
directory "/usr/local/bind";
recursion no;
listen-on { any;};
listen-on-v6 {any; };
[...]
};

[...]

zone "." {
type hint;
file "named.root";
};

zone "localhost" {
type master;
file "localhost";
};

// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};

// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour
// l'adresse loopback en IPv6

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.rev";
};

[...]

zone "nic.fr" {
type slave;
file "zone/nic.fr";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24

zone "0.134.192.in-addr.arpa" {
type slave;
file "rev/nic.fr.192.134.0";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Blocs Ripe sous ip6.arpa.

zone "6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.1.0.0.2.ip6.arpa";
masters {
2001:610:240:0:53::3;
193.0.0.195;
};
};

[...]

// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48

zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

L'option « <tt>listen-on</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut).

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur <tt>ns3.nic.fr</tt> fait autorité.

====Fichier de zone DNS direct ====

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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épendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007102200 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1 IN A 192.93.0.1
IN AAAA 2001:660:3005:1::1:1
ns2 IN A 192.93.0.4
IN AAAA 2001:660:3005:1::1:2
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1

[...]

www IN CNAME rigolo
rigolo IN A 192.134.4.20
IN AAAA 2001:660:3003:2::4:20

kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98

[...]

====. Fichier de zone DNS inverse en IPv6 ====

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 <tt>2001:660:3003::/48</tt> (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007031200 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 );
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

=== Recommandations opérationnelles pour l'intégration d'IPv6 ===

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

==== Les deux aspects du DNS ====

En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

==== Continuité du service DNS ====

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

* premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
* second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « <tt>options</tt> » dans le fichier <tt>named.conf</tt>.

==== Taille limitée des messages DNS en UDP ====

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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 <tt>TC</tt> (''Truncated'') est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.

Notons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : http://www.root-servers.org/ .

==== Glue IPv6 ====

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.

==== Publication des enregistrements AAAA dans le DNS ====

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

* l'équipement <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;
* les serveurs web et dns s'exécutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;
* une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
* un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;
* la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.

MOOC:Compagnon Act34-s6

2015-06-06T17:58:20Z

Nbenamar: /* Introduction */

= Le système de nommage en IPv6 =
== Introduction ==

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier <tt>hosts.txt</tt> (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence <tt>/etc/hosts</tt> pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses.

Paul Mockapetris, de l'Université de Californie, a conçu le système des noms de domaine (DNS) en 1983, et a écrit la première mise en œuvre à la demande de Jon Postel. Le DNS permet de résoudre un nom de domaine, un mécanisme qui consiste à trouver l'adresse IP qui lui est associée.

Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

* hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
* réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
* et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

== Spécifications ==

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully Qualified Domain Name'') garantissant l'unicité du nom (exemple : <tt>ns3.nic.fr</tt>) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : ''Resource Records'') et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type <tt>MX</tt>) ou les serveurs de noms (enregistrement de type <tt>NS</tt>).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier <tt>/etc/resolv.conf</tt> fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

* l'enregistrement <tt>AAAA</tt> (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
* le nouveau sous-arbre DNS inverse <tt>ip6.arpa</tt> pour le nommage inverse (correspondance : adresse vers nom)

=== Nommage direct : enregistrement AAAA ===

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement <tt>AAAA</tt> défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements <tt>AAAA</tt> publiés dans le DNS. Une requête DNS de type <tt>AAAA</tt> concernant une machine particulière retourne dans ce cas tous les enregistrements <tt>AAAA</tt> publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe [[NommageBis#3.4.5._Publication_des_enregistrements_AAAA_dans_le_DNS|Publication des enregistrements AAAA dans le DNS]]. {{ToDo|envoyer vers la bonne référence}}

Le format textuel d'un enregistrement <tt>AAAA</tt> tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine <tt>ns3.nic.fr</tt> est publiée dans le fichier de zone <tt>nic.fr</tt> comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné, doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de <tt>ns3.nic.fr</tt> sont publiées dans le fichier de zone <tt>nic.fr</tt> comme suit :

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

=== Nommage inverse : enregistrement PTR ===

L'enregistrement de type <tt>PTR</tt>, stocké sous l'arbre DNS inverse <tt>in-addr.arpa</tt>, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement <tt>PTR</tt>, qui, stocké sous l'arbre DNS inverse <tt>ip6.arpa</tt>, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : <tt>ip6.int</tt>. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse <tt>ip6.arpa</tt> de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `<tt>.</tt>' et concaténés dans l'ordre inverse au suffixe <tt>ip6.arpa</tt>.

Par exemple l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de <tt>ns3.nic.fr</tt>) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement <tt>PTR</tt> correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `<tt>ns3.nic.fr.</tt>'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements <tt>PTR</tt> sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

* 1) L'[http://www.iana.org/ IANA] délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
* 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions [http://www.apnic.net/ APNIC] et [http://www.lacnic.net/ LACNIC], il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
* 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

[[image:Fig6-1.png|thumb|right|400px|Figure 6-1 ''Exemple de délégation de zones inverse'']]

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse <tt>0.6.6.0.1.0.0.2.ip6.arpa</tt> de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe <tt>2001:660:3006::/48</tt> et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

== Mises en oeuvre ==

''Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''

=== Logiciels DNS supportant IPv6 ===

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements <tt>AAAA</tt> et <tt>PTR</tt>) et au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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 celle du serveur. Par exemple, la [http://www.isc.org/software/bind distribution BIND 9] développée par l'[http://www.isc.org ISC] (''Internet Systems Consortium'') représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons que les logiciels DNS développés par les [http://www.nlnetlabs.nl NLnetLabs] sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS faisant autorité (sans récursion) et [http://unbound.net/ Unbound] comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :
* pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
* pour la diversification de leur plates-formes logicielles (on parle souvent de ''diversité génétique'').

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

=== Clients et outils de vérification de configurations DNS ===

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

==== Exemples d'interrogation ====

Les six exemples suivants illustrent l'utilisation des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> pour la même requête de résolution du nom `<tt>ns3.nic.fr</tt>' en adresse(s) IPv6 :

>'''dig ns3.nic.fr aaaa'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

>'''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:

[...]

;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

>'''host -t aaaa ns3.nic.fr'''
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''host -t aaaa ns3.nic.fr ns-sec.ripe.net'''
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53
Aliases:

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''nslookup -type=aaaa ns3.nic.fr'''
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53

Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

[...]

>'''nslookup -type=aaaa ns3.nic.fr -secripe.net'''
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (<tt>2001:660:3003:2::1:1</tt>). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur <tt>ns-sec.ripe.net</tt> (qui est secondaire pour la zone <tt>nic.fr</tt>).

Notons que l'outil <tt>nslookup</tt> n'est plus maintenu par l'[http://www.isc.org/ ISC] et qu'il est amené à disparaître. L'usage de l'outil <tt>dig</tt> ou de <tt>host</tt> pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de <tt>ZoneCheck</tt>, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, [http://www.zonecheck.fr/ ZoneCheck] permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

=== Configuration de serveur/zone DNS ===

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

==== Fichier de configuration d'un serveur BIND9 ====

Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> :

options {
directory "/usr/local/bind";
recursion no;
listen-on { any;};
listen-on-v6 {any; };
[...]
};

[...]

zone "." {
type hint;
file "named.root";
};

zone "localhost" {
type master;
file "localhost";
};

// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};

// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour
// l'adresse loopback en IPv6

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.rev";
};

[...]

zone "nic.fr" {
type slave;
file "zone/nic.fr";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24

zone "0.134.192.in-addr.arpa" {
type slave;
file "rev/nic.fr.192.134.0";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Blocs Ripe sous ip6.arpa.

zone "6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.1.0.0.2.ip6.arpa";
masters {
2001:610:240:0:53::3;
193.0.0.195;
};
};

[...]

// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48

zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

L'option « <tt>listen-on</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut).

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur <tt>ns3.nic.fr</tt> fait autorité.

====Fichier de zone DNS direct ====

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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épendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007102200 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1 IN A 192.93.0.1
IN AAAA 2001:660:3005:1::1:1
ns2 IN A 192.93.0.4
IN AAAA 2001:660:3005:1::1:2
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1

[...]

www IN CNAME rigolo
rigolo IN A 192.134.4.20
IN AAAA 2001:660:3003:2::4:20

kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98

[...]

====. Fichier de zone DNS inverse en IPv6 ====

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 <tt>2001:660:3003::/48</tt> (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007031200 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 );
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

=== Recommandations opérationnelles pour l'intégration d'IPv6 ===

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

==== Les deux aspects du DNS ====

En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

==== Continuité du service DNS ====

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

* premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
* second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « <tt>options</tt> » dans le fichier <tt>named.conf</tt>.

==== Taille limitée des messages DNS en UDP ====

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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 <tt>TC</tt> (''Truncated'') est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.

Notons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : http://www.root-servers.org/ .

==== Glue IPv6 ====

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.

==== Publication des enregistrements AAAA dans le DNS ====

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

* l'équipement <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;
* les serveurs web et dns s'exécutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;
* une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
* un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;
* la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.

MOOC:Compagnon Act34-s6

2015-06-06T17:46:30Z

Nbenamar: /* Introduction */

= Le système de nommage en IPv6 =
== Introduction ==

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans un fichier centralisé, le fichier <tt>hosts.txt</tt> (RFC 608). Ce fichier pouvait alors être téléchargé (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence <tt>/etc/hosts</tt> pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses. À la demande de la DARPA, Jon Postel et Paul Mockapetris ont conçu le « Domain Name System » en 1983 et en écrivirent la première réalisation. Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

* hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable ») ;
* réparti : au niveau de chaque nœud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce nœud. Cet ensemble de serveurs représente la source officielle des données de la zone,
* et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

== Spécifications ==

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : ''Fully Qualified Domain Name'') garantissant l'unicité du nom (exemple : <tt>ns3.nic.fr</tt>) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : ''Resource Records'') et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type <tt>MX</tt>) ou les serveurs de noms (enregistrement de type <tt>NS</tt>).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier <tt>/etc/resolv.conf</tt> fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

* l'enregistrement <tt>AAAA</tt> (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
* le nouveau sous-arbre DNS inverse <tt>ip6.arpa</tt> pour le nommage inverse (correspondance : adresse vers nom)

=== Nommage direct : enregistrement AAAA ===

La correspondance entre un nom de domaine et son (ou ses) adresse(s) IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

De manière analogue à l'enregistrement A, le nouveau type d'enregistrement <tt>AAAA</tt> défini pour IPv6, permet d'établir la correspondance entre un nom de domaine et son (ou une de ses) adresse(s) IPv6. Une machine ayant plusieurs adresses IPv6 globales a en principe autant d'enregistrements <tt>AAAA</tt> publiés dans le DNS. Une requête DNS de type <tt>AAAA</tt> concernant une machine particulière retourne dans ce cas tous les enregistrements <tt>AAAA</tt> publiés dans le DNS et correspondant à cette machine. Toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au paragraphe [[NommageBis#3.4.5._Publication_des_enregistrements_AAAA_dans_le_DNS|Publication des enregistrements AAAA dans le DNS]]. {{ToDo|envoyer vers la bonne référence}}

Le format textuel d'un enregistrement <tt>AAAA</tt> tel qu'il apparaît dans le fichier de zone DNS est le suivant :

<nom> [ttl] IN AAAA <adresse>

L'adresse est écrite suivant la représentation classique des adresses IPv6 (RFC 4291). Par exemple, l'adresse IPv6 de la machine <tt>ns3.nic.fr</tt> est publiée dans le fichier de zone <tt>nic.fr</tt> comme suit :

ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1

Il est important de noter que toutes les adresses IPv4 et/ou IPv6 correspondant à un équipement donné, doivent cohabiter dans le même fichier de zone renseignant le nom de l'équipement en question. Ainsi, les adresses de <tt>ns3.nic.fr</tt> sont publiées dans le fichier de zone <tt>nic.fr</tt> comme suit :

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

=== Nommage inverse : enregistrement PTR ===

L'enregistrement de type <tt>PTR</tt>, stocké sous l'arbre DNS inverse <tt>in-addr.arpa</tt>, permet d'établir la correspondance entre une adresse IPv4 et un (ou plusieurs) nom(s). C'est ce même type d'enregistrement <tt>PTR</tt>, qui, stocké sous l'arbre DNS inverse <tt>ip6.arpa</tt>, permet de mettre en correspondance une adresse IPv6 avec un ou plusieurs noms de domaines.

Notons au passage qu'auparavant, le RFC 1886, rendu obsolète par le RFC 3596, spécifiait une autre arborescence : <tt>ip6.int</tt>. Cette dernière a été arrêtée en 2006.

Une adresse IPv6 est transformée en un nom de domaine publié sous l'arborescence inverse <tt>ip6.arpa</tt> de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère `<tt>.</tt>' et concaténés dans l'ordre inverse au suffixe <tt>ip6.arpa</tt>.

Par exemple l'adresse <tt>2001:660:3006:1::1:1</tt> (adresse de <tt>ns3.nic.fr</tt>) est transformée en le nom de domaine inverse suivant :

1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.

On publie alors dans le DNS inverse l'enregistrement <tt>PTR</tt> correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, l'enregistrement PTR vaut `<tt>ns3.nic.fr.</tt>'

En pratique, on procède par délégation de zones inverses afin de répartir les enregistrements <tt>PTR</tt> sur un système hiérarchique de serveurs DNS. Soulignons que la délégation DNS inverse suit le schéma classique d'attribution des adresses IP (le même pour IPv4 et IPv6) :

* 1) L'[http://www.iana.org/ IANA] délègue (en terme de provision) de larges blocs d'adresses IPv6 aux registres Internet régionaux (RIR : Regional Internet Registry ), typiquement des préfixes de longueur 12 selon la politique actuelle
* 2) Les RIR allouent (en terme de provision) des blocs d'adresses IPv6 plus petits aux registres Internet locaux (LIR : Local Internet Registry), c'est-à-dire aux fournisseurs d'accès Internet de la région, typiquement des préfixes de longueur 32 (ou plus courts selon le besoin). À noter que dans les régions [http://www.apnic.net/ APNIC] et [http://www.lacnic.net/ LACNIC], il existe des Registres nationaux (NIR) comme registres intermédiaires entre le RIR et les LIR présents dans le pays en question.
* 3) Les LIR attribuent (pour un usage direct) des préfixes IPv6 aux clients finaux, typiquement des préfixes de longueur variable entre un /64 et un /48 (selon le besoin et selon la politique en vigueur).

[[image:Fig6-1.png|thumb|right|400px|Figure 6-1 ''Exemple de délégation de zones inverse'']]

À chaque nœud présent dans l'arborescence DNS inverse, illustrée par la figure Exemple de délégation de zones inverse, est associée une liste de serveurs DNS qui héberge la zone inverse décrivant ce nœud. Une telle liste comprend généralement un serveur primaire et un ou plusieurs serveurs secondaires, tous considérés comme faisant autorité sur la zone DNS inverse en question. C'est au client final, de publier dans ses propres zones DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 qu'il utilise.

Par exemple, Renater a reçu le préfixe <tt>2001:660::/32</tt> et la délégation de la zone DNS inverse <tt>0.6.6.0.1.0.0.2.ip6.arpa</tt> de la part du RIPE-NCC. Renater a affecté à l'AFNIC le préfixe <tt>2001:660:3006::/48</tt> et lui a délégué la zone DNS inverse correspondante :

6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.
6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.

L'AFNIC publie alors dans sa zone DNS inverse les enregistrements <tt>PTR</tt> correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS :

$ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.

== Mises en oeuvre ==

''Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''

=== Logiciels DNS supportant IPv6 ===

Il existe aujourd'hui de nombreux logiciels DNS mais la présente 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 page suivante : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

Dans leurs versions récentes, la plupart de ces logiciels DNS supportent IPv6 complètement, c'est-à-dire à la fois au niveau de la base de données (enregistrements <tt>AAAA</tt> et <tt>PTR</tt>) et au niveau transport IPv6 des messages DNS.

Néanmoins, certains ne supportent encore IPv6 qu'au niveau de la base de données.

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 celle du serveur. Par exemple, la [http://www.isc.org/software/bind distribution BIND 9] développée par l'[http://www.isc.org ISC] (''Internet Systems Consortium'') représente la référence de fait dans le domaine. En effet, il s'agit d'un logiciel complet (client, serveur et outils) intégrant toutes les extensions DNS récentes (IPv6, DNSSEC...). Les distributions BIND 9 ont l'avantage d'être disponibles en code source et en format binaire pour la quasi-totalité des plates-formes (Unix, MS Windows*...). Ainsi, la distribution BIND 9 a été choisie comme base pour les exemples de fichiers de configuration.

Notons que les logiciels DNS développés par les [http://www.nlnetlabs.nl NLnetLabs] sont aussi des logiciels libres et qu'ils présentent en outre l'avantage d'être dédiés à une seule fonction, à savoir, récursif ou faisant autorité uniquement. Ainsi, de plus en plus d'opérateurs DNS tournent aujourd'hui le serveur récursif [http://www.nlnetlabs.nl/projects/nsd/ NSD] comme serveur DNS faisant autorité (sans récursion) et [http://unbound.net/ Unbound] comme serveur récursif pour l'une et/ou l'autre de ces deux raisons :
* pour leur performance reconnue (des tests de performance d'un côté entre NSD et BIND et de l'autre entre Unbound et BIND montrent la supériorité du premier sur le second) ;
* pour la diversification de leur plates-formes logicielles (on parle souvent de ''diversité génétique'').

Enfin, des comparaisons multicritères entre les différentes implémentations sont présentées ici : [http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software]

=== Clients et outils de vérification de configurations DNS ===

Un client DNS se présente souvent sous forme d'une bibliothèque de résolution appelée « <tt>libresolv</tt> », le client est alors appelé « resolver » ou encore « stub resolver ». Rappelons que ce resolver est sollicité par les applications TCP/IP s'exécutant sur un équipement donné pour les renseigner sur les ressources DNS nécessaires à l'établissement de leur communication avec des applications distantes. Outre le resolver, il existe des outils et commandes selon le système d'exploitation, qui permettent d'interroger un serveur DNS dans un but de débogage et/ou de diagnostic. C'est le cas par exemple des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> qui font partie des distributions BIND et pour lesquels des exemples sont donnés ci-après.

Notons que lorsque le serveur à interroger n'est pas explicitement renseigné, c'est le (ou les) serveurs par défaut qui est (sont) interrogé(s). Il s'agit de la liste des serveurs récursifs qui est configurée automatiquement (via DHCP par exemple) ou manuellement (dans le fichier <tt>/etc/resolv.conf</tt> pour les systèmes Unix par exemple ou au travers d'une interface graphique pour MS Windows et Mac OS) sur l'équipement. Les mécanismes de découverte de la liste des serveurs DNS récursifs seront décrits plus loin dans la section découverte de la liste de serveurs DNS récursifs, See Découverte de la liste de serveurs DNS récursifs. L'exemple suivant décrit un fichier <tt>resolv.conf</tt> sous Unix :

search nic.fr # domaine de recherche par défaut
nameserver ::1 # prefer localhost-v6
nameserver 192.134.4.162 # backup v4

==== Exemples d'interrogation ====

Les six exemples suivants illustrent l'utilisation des outils <tt>dig</tt>, <tt>host</tt> et <tt>nslookup</tt> pour la même requête de résolution du nom `<tt>ns3.nic.fr</tt>' en adresse(s) IPv6 :

>'''dig ns3.nic.fr aaaa'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:
nic.fr. 78032 IN NS ns1.nic.fr.
nic.fr. 78032 IN NS ns2.nic.fr.
nic.fr. 78032 IN NS ns3.nic.fr.
nic.fr. 78032 IN NS ns-sec.ripe.net.
[...]

;; ADDITIONAL SECTION:
ns1.nic.fr. 78032 IN A 192.93.0.1
ns1.nic.fr. 17168 IN AAAA 2001:660:3005:1::1:1
ns2.nic.fr. 25737 IN A 192.93.0.4
ns2.nic.fr. 25737 IN AAAA 2001:660:3005:1::1:2
ns-sec.ripe.net. 96368 IN A 193.0.0.196
ns-sec.ripe.net. 96368 IN AAAA 2001:610:240:0:53::4

;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Oct 25 19:13:54 2007
;; MSG SIZE rcvd: 350

>'''dig ns3.nic.fr aaaa @ns-sec.ripe.net'''

; <<>> DiG 9.3.3 <<>> ns3.nic.fr aaaa @ns-sec.ripe.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16927
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 5

;; QUESTION SECTION:
;ns3.nic.fr. IN AAAA

;; ANSWER SECTION:
ns3.nic.fr. 345600 IN AAAA 2001:660:3006:1::1:1

;; AUTHORITY SECTION:

[...]

;; SERVER: 2001:610:240:0:53::4#53(ns-sec.ripe.net)

>'''host -t aaaa ns3.nic.fr'''
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''host -t aaaa ns3.nic.fr ns-sec.ripe.net'''
Using domain server:
Name: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53
Aliases:

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

>'''nslookup -type=aaaa ns3.nic.fr'''
Server: 2001:660:3003:2::1:1
Address: 2001:660:3003:2::1:1#53

Non-authoritative answer:
ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

[...]

>'''nslookup -type=aaaa ns3.nic.fr -secripe.net'''
Server: ns-sec.ripe.net
Address: 2001:610:240:0:53::4#53

ns3.nic.fr has AAAA address 2001:660:3006:1::1:1

Dans les exemples 1, 3 et 5, la requête est envoyée au serveur récursif par défaut (<tt>2001:660:3003:2::1:1</tt>). Dans les exemples 2, 4 et 6, la requête est envoyée au serveur <tt>ns-sec.ripe.net</tt> (qui est secondaire pour la zone <tt>nic.fr</tt>).

Notons que l'outil <tt>nslookup</tt> n'est plus maintenu par l'[http://www.isc.org/ ISC] et qu'il est amené à disparaître. L'usage de l'outil <tt>dig</tt> ou de <tt>host</tt> pour toutes sortes de requêtes est en revanche recommandé.

La deuxième version de <tt>ZoneCheck</tt>, l'outil utilisé par l'AFNIC pour vérifier la configuration et valider la délégation de zones DNS sous .fr et .re, supporte IPv6 complètement. En effet, pour une zone DNS quelconque, [http://www.zonecheck.fr/ ZoneCheck] permet d'interroger la liste des serveurs faisant autorité sur cette zone afin de vérifier leur bon fonctionnement (en termes de transport UDP et TCP au-dessus d'IPv4 et d'IPv6 si IPv6 est supporté) et la bonne configuration de la zone DNS en question (en termes de base de données, notamment concernant la cohérence des enregistrements DNS entre serveurs différents).

=== Configuration de serveur/zone DNS ===

Même si les logiciels DNS utilisés sont interopérables, leur syntaxe et règles de configuration peuvent être très différentes d'une implémentation à l'autre. Dans ce chapitre, nous avons choisi de fournir des exemples suivant la syntaxe et les règles de BIND 9, logiciel considéré aujourd'hui comme l'implémentation de référence.

==== Fichier de configuration d'un serveur BIND9 ====

Pour un serveur de nom BIND 9, le fichier de configuration named.conf contient une succession de parties déclaratives. La partie <tt>options</tt> par exemple, indique au serveur les différentes options de configuration telles que l'activation de l'écoute (socket) en IPv4 et/ou en IPv6, l'activation ou non du mode récursif ou le chemin d'accès aux données (option directory).

Les zones DNS sur lesquelles le serveur fait autorité (primaire ou secondaire) sont ensuite déclarées successivement grâce à des rubriques de type zone. Pour chaque zone, le nom du fichier contenant les enregistrements de cette zone est précisé. Lorsque le serveur est secondaire pour une zone donnée, on indique (à l'aide de la sous-rubrique <tt>masters</tt> ) la liste des adresses IPv4 et/ou IPv6 des serveurs à partir desquels ce secondaire peut s'alimenter. Voici maintenant un extrait du fichier <tt>named.conf</tt> du serveur DNS <tt>ns3.nic.fr</tt> :

options {
directory "/usr/local/bind";
recursion no;
listen-on { any;};
listen-on-v6 {any; };
[...]
};

[...]

zone "." {
type hint;
file "named.root";
};

zone "localhost" {
type master;
file "localhost";
};

// Zone contenant l'enregistrement inverse pour l'adresse loopback en IPv4

zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};

// Zone inverse (sous ipv6.arpa) contenant l'enregistrement inverse pour
// l'adresse loopback en IPv6

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "localhost.rev";
};

[...]

zone "nic.fr" {
type slave;
file "zone/nic.fr";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Zone inverse IPv4 pour la réseau AFNIC-SFINX en 192.134.0/24

zone "0.134.192.in-addr.arpa" {
type slave;
file "rev/nic.fr.192.134.0";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

// Blocs Ripe sous ip6.arpa.

zone "6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.1.0.0.2.ip6.arpa";
masters {
2001:610:240:0:53::3;
193.0.0.195;
};
};

[...]

// Zone inverse IPv6 pour le reseau AFNIC-SFINX en 2001:660:3006::/48

zone "6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "rev/6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa";
masters {
2001:660:3005:1::1:1; 192.93.0.1;
2001:660:3005:1::1:2; 192.93.0.4;
};
};

[...]

L'option « <tt>listen-on</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ces adresses IPv4 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv4 données : le serveur écoutera uniquement sur ses adresses pour ce qui est du transport IPv4 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv4 (cette valeur n'est pas utilisée aujourd'hui).

L'option « <tt>listen-on-v6</tt> » peut avoir comme valeurs possibles :
* <tt>any</tt> : dans ce cas-là, le serveur écoutera sur toutes ses adresses IPv6 opérationnelles ;
* une liste explicite comprenant une ou plusieurs adresses IPv6 données : le serveur écoutera uniquement sur ces adresses pour ce qui est du transport IPv6 des requêtes et réponses ;
* <tt>none</tt> : pas de support d'IPv6 (valeur par défaut).

Les cinq premières zones déclarées font partie de la configuration d'un serveur BIND de base. Les quatre zones restantes sont données à titre d'exemple parmi les nombreuses zones sur lesquelles le serveur <tt>ns3.nic.fr</tt> fait autorité.

====Fichier de zone DNS direct ====

Voici à titre d'exemple, un extrait du fichier de zone DNS direct `<tt>nic.fr</tt>', faisant apparaître en même temps des adresses IPv4 et IPv6. On remarquera 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épendent généralement de l'adresse physique de la carte réseau utilisée (RFC 4291).

$TTL 172800
$ORIGIN nic.fr.
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007102200 ;serial
21600 ;refresh (6 h)
3600 ;retry (1 h)
3600000 ;expire
86400 ) ;minimum (2 j)

IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
IN MX 10 mx1.nic.fr.
IN MX 20 mx2.nic.fr.
[...]

ns1 IN A 192.93.0.1
IN AAAA 2001:660:3005:1::1:1
ns2 IN A 192.93.0.4
IN AAAA 2001:660:3005:1::1:2
ns3 IN A 192.134.0.49
IN AAAA 2001:660:3006:1::1:1

[...]

www IN CNAME rigolo
rigolo IN A 192.134.4.20
IN AAAA 2001:660:3003:2::4:20

kerkenna IN A 192.134.4.98
IN AAAA 2001:660:3003:8::4:98

[...]

====. Fichier de zone DNS inverse en IPv6 ====

Voici un extrait de fichier de zone DNS inverse correspondant au préfixe IPv6 <tt>2001:660:3003::/48</tt> (réseau AFNIC-Saint-Quentin-en-Yvelines) et représentant quelques enregistrements de type PTR d'équipements supportant IPv6 :

$ORIGIN 3.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.
$TTL 172800
@ IN SOA maya.nic.fr. hostmaster.nic.fr. (
2007031200 ;serial
43200 ;refresh (12 h)
14400 ;retry (4 h)
3600000 ;expire
3600 );
IN NS ns1.nic.fr.
IN NS ns2.nic.fr.
IN NS ns3.nic.fr.
[...]
0.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR rigolo.nic.fr.
7.2.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR funk.nic.fr.
1.3.0.0.4.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR wood.nic.fr.
8.9.0.0.4.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0 IN PTR kerkenna.nic.fr.
[...]

=== Recommandations opérationnelles pour l'intégration d'IPv6 ===

Comme cela a été décrit dans l'introduction de ce chapitre, le DNS a la particularité d'être à la fois une application TCP/IP et une infrastructure critique (en tant que base de données) pour le fonctionnement des autres applications TCP/IP classiques (web, mail, ftp, ...). Avec l'intégration progressive d'IPv6, de nouveaux problèmes opérationnels liés au DNS se posent ou risquent de se poser et il convient donc de les éviter ou de trouver tout au moins les solutions adéquates afin d'y remédier. À cet effet, RFC 3901 et RFC 4472 identifient les principaux problèmes et formulent une série de recommandations pratiques pour y faire face. Les sections qui suivent tentent de résumer ces recommandations.

==== Les deux aspects du DNS ====

En tant que base de données, le DNS supporte les enregistrements <tt>A</tt> et <tt>AAAA</tt> et ce, indépendamment de la version d'IP qui est utilisée pour transporter les requêtes et réponses DNS relatives à ces enregistrements. Par ailleurs, en tant qu'application TCP/IP, un serveur DNS supporte le transport IPv4 ou le transport IPv6 ou les deux à la fois. Dans tous les cas, il doit retourner ce qu'il a dans sa base de données pour répondre à une requête donnée, indépendamment de la version d'IP sur laquelle il a reçu cette requête. En effet, un serveur DNS ne peut a priori pas savoir si le client initiateur de la requête a transmis celle-ci en IPv4 ou en IPv6 à son serveur récursif (cache) : des serveurs intermédiaires appelés cache forwarders et n'utilisant pas la même version d'IP que le client, peuvent intervenir dans la chaîne des serveurs interrogés durant le processus de résolution DNS. En outre, en admettant même que le serveur DNS puisse connaître la version d'IP utilisée par le client qui a initié la requête, il faut souligner que le serveur n'a pas à faire d'hypothèse sur l'usage que fera le client de la réponse DNS retournée.

==== Continuité du service DNS ====

Avant l'arrivée d'IPv6, le processus de résolution DNS ne faisait intervenir que la version 4 d'IP et le service était donc garanti pour tous les clients DNS. Avec IPv6, on risque de se trouver dans des configurations où l'espace de nommage devient fragmenté en des partitions accessibles uniquement au-dessus d'IPv4 et d'autres accessibles uniquement au-dessus d'IPv6. Voici par exemple deux scénarios illustrant ce problème de fragmentation ainsi que la solution recommandée dans chaque scénario :

* premier scénario : un client ne supportant qu'IPv4 souhaite résoudre une requête relative à une zone DNS hébergée sur des serveurs ne supportant qu'IPv6. Dans ces cas-là, le processus de résolution se termine par un échec dû à l'impossibilité d'accéder aux serveurs qui font autorité sur cette zone. Pour y remédier, il faudra faire en sorte que toute zone DNS soit servie par au moins un serveur supportant IPv4.
* second scénario : un client DNS dans un réseau ne supportant qu'IPv6 souhaite résoudre une requête donnée. Si le serveur récursif interrogé ne supporte pas non plus IPv4, le processus de résolution risque d'échouer plus tard avant de joindre les serveurs faisant autorité sur l'information recherchée. En effet, lors de son parcours de la chaîne de délégations dans l'arborescence DNS, le serveur récursif risque de tomber sur un serveur ne supportant pas IPv6. Afin d'y remédier, il est recommandé dans ce cas, de configurer le serveur récursif en le faisant pointer vers un serveur <tt>forwarder</tt> en double pile IPv4/IPv6.

Par exemple, pour une distribution BIND, il suffit d'ajouter l'option :

forwarders {<liste des adresses de serveurs forwarders> ;}

sous la rubrique « <tt>options</tt> » dans le fichier <tt>named.conf</tt>.

==== Taille limitée des messages DNS en UDP ====

Les implémentations DNS s'appuient essentiellement sur deux standards de l'IETF (RFC 1034 et RFC 1035). De nombreux autres RFC complémentaires ont été publiés plus tard pour clarifier certains aspects pratiques ou pour apporter de nouvelles extensions répondant à de nouveaux besoins (enregistrements <tt>AAAA</tt>, <tt>SRV</tt>, extensions DNSSEC, ...). En tant qu'application TCP/IP, le DNS doit supporter les deux modes de transport UDP et TCP (RFC 1035), le port associé étant le même : 53.

Le mode UDP est généralement utilisé pour les requêtes/réponses DNS et le mode TCP est généralement utilisé pour les transferts de zones. Cependant, compte tenu de la taille limitée à 512 octets des messages DNS en mode UDP, certaines requêtes peuvent provoquer le passage en mode TCP si la taille de la réponse dépasse cette limite.

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 <tt>TC</tt> (''Truncated'') est positionné, ce qui signifie implicitement que le client est invité à réinterroger le serveur en mode TCP. Au passage, ce scénario constitue un argument justifiant le fait que le port 53 en TCP ne doit pas être ouvert exclusivement pour les transferts de zones.

Notons qu'un basculement trop fréquent en mode TCP risque de consommer davantage de ressources et dégrader par conséquent les performances du serveur DNS. Certains nouveaux types d'enregistrements (tels que le type <tt>AAAA</tt>) risquent d'augmenter la taille des réponses DNS de manière significative, ce qui risque de faire basculer plus souvent les requêtes/réponses DNS en mode TCP. Aujourd'hui, ce dépassement n'arrive que rarement car la plupart des réponses DNS ne dépasse guère les 400 octets. En effet, les sections <tt>answer</tt>, <tt>authority</tt> et <tt>additional</tt>, qui constituent la majeure partie de la réponse DNS, ne contiennent qu'un nombre limité d'enregistrements si cette réponse ne concerne pas directement une zone de haut niveau telle que <tt>.com</tt>, <tt>.net</tt>, <tt>.fr</tt>, <tt>.de</tt>...

Face à ce risque, l'extension EDNS.0 (RFC 2671) a été proposée et est déjà déployée dans les versions récentes des logiciels DNS. Cette extension, permet à un client DNS d'informer le serveur interrogé qu'il est capable de supporter des réponses de taille supérieure à la limite des 512 octets (4096 octets par exemple). Ainsi, en présence d'IPv6, le support d'EDNS.0 devient fortement recommandé. À noter que le support d'EDNS.0 devient également indispensable en présence des extensions DNSSEC.

Le faible taux de pénétration d'EDNS.0 dans les logiciels DNS (surtout les clients) est resté pendant plusieurs années l'un des principaux motifs du refus de l'IANA/ICANN de publier de nouvelles adresses (IPv4 ou IPv6) pour des serveurs de la racine. À partir du 4 février 2008, l'[http://www.iana.org IANA] publie dans la zone racine l'adresse IPv6 (enregistrement AAAA) des serveurs racine supportant le transport IPv6 et la nouvelle version du fichier de de démarrage (typiquement <tt>named.root</tt> pour BIND 9) contient également ces adresses.

Notons enfin que des informations sur les adresses IPv4 et IPv6 des serveurs de la racine ainsi que sur la répartition géographique de ces serveurs sont publiées sur le site web : http://www.root-servers.org/ .

==== Glue IPv6 ====

La zone racine publie également les adresses des différents serveurs DNS pour chacun des domaines de haut niveau (TLD : ''Top Level Domain''). Ces adresses, appelées « glues » sont nécessaires pour que le processus de résolution DNS puisse démarrer. En effet, rappelons que les serveurs DNS de la racine ne sont pas censés résoudre eux-mêmes les requêtes. Leur rôle est de faire le premier aiguillage (''referal'') vers des serveurs de haut niveau (TLD). L'information d'aiguillage comprend la liste des serveurs du TLD sous l'arborescence duquel se trouve la ressource ainsi que les adresses (glues) associées à ces serveurs. Sans ces glues, le processus de résolution risque de tourner en rond.

En attendant que les serveurs de la racine puissent recevoir des requêtes DNS et y répondre en IPv6, les TLD avaient œuvré pendant des années à l'introduction dans la zone racine des « glues » IPv6 qui lui sont associées. L'IANA/ICANN ont enfin été convaincus que la publication des glues IPv6 des serveurs DNS de TLD supportant IPv6 peut se faire sans risque pour la stabilité du DNS. L'ICANN/IANA a démarré en juillet 2004 la publication des glues IPv6 des TLD dans la zone racine. Les trois TLD <tt>.fr</tt>, <tt>.jp</tt> et <tt>.kr</tt> ont vu les premiers leur glue IPv6 publiée.

==== Publication des enregistrements AAAA dans le DNS ====

On choisit généralement de publier dans le DNS le (ou les) enregistrement(s) <tt>AAAA</tt> associé(s) à un équipement donné lorsque l'on souhaite que les applications initiant des communications à destination de cet équipement découvrent le support du transport IPv6. Par exemple, un navigateur supportant IPv6, découvre via le DNS qu'il est possible de se connecter en IPv6 au site <tt><nowiki>http://www.afnic.fr/</nowiki></tt>. 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, certaines applications s'exécutant sur l'équipement dont l'adresse IPv6 est publiée dans le DNS peuvent ne pas supporter IPv6. Ainsi, l'on risque de se trouver par exemple dans la situation suivante :

* l'équipement <tt>foo.example.com</tt> héberge plusieurs services : web, ftp, mail, dns ;
* les serveurs web et dns s'exécutant sur <tt>foo.example.com</tt> supportent IPv6 mais pas les serveurs ftp et mail ;
* une adresse IPv6 est publiée dans le DNS pour <tt>foo.example.com</tt> ;
* un client ftp supportant IPv6 tente de se connecter au serveur s'exécutant sur <tt>foo.example.com</tt>. Le client sélectionne alors l'adresse IPv6 de <tt>foo.example.com</tt> comme adresse destination ;
* la tentative de communication en IPv6 échoue. Selon les implémentations, certains clients réessaient (ou non) d'autres adresses IPv6 s'il y en a ou passent (ou non) en IPv4 en dernier recours.

Afin de pallier ce problème, il est recommandé 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 <tt>www.example.com</tt> et <tt>ns.example.com</tt> avec adresses IPv6 (et IPv4 éventuellement) et d'autre part, les noms <tt>ftp.example.com</tt> et <tt>mail.example.com</tt> avec des adresses IPv4 uniquement. L'enregistrement <tt>AAAA</tt> pour <tt>foo.example.com</tt> n'est alors publié que lorsque l'on a la certitude que toutes les applications s'exécutant sur cet équipement supportent IPv6.

Par ailleurs, le DNS étant une ressource publique, il est fortement déconseillé (sauf si l'administrateur DNS sait très bien ce qu'il/elle fait !) d'y publier des adresses IPv6 non joignables de l'extérieur, soit à cause d'une portée faible (adresses [[Lien-local|lien-local]] par exemple), soit parce que toutes les communications provenant de l'extérieur du réseau et allant vers ces adresses sont filtrées. Notons que cette règle est déjà appliquée pour les adresses IPv4 privées (RFC 1918) et que certains logiciels DNS récents supportent aujourd'hui les vues DNS (on parle de ''two-face DNS'', de ''split-view DNS'' ou encore de ''split DNS''). Avec ce système de vues, la réponse à une requête DNS dépend de l'origine du client. Par exemple un client appartenant au réseau interne pourra voir les adresses privées des équipements. Les clients externes, quant à eux, ne verront que les adresses globales et joignables de l'extérieur.

MOOC:Matrice des séquences

2015-03-08T21:44:40Z

Nbenamar:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|gestion de projet]] > [[MOOC:Matrice_des_séquences| Matrice des séquences]]
----

{| border="1" cellpadding="10" cellspacing="0"
! colspan="2" | Séquences
! Intervenants
! Contributeurs
! Relecteurs
|-
! rowspan="6" | [[MOOC:Semaine 1|Semaine 1]]
| [[MOOC:Séquence 11|Seq11: Intro sur l'évolution de l'adressage]]
| J.landru
| N. Benamar
|
|-
| [[MOOC:Séquence 12|Seq 12: Notation d’une adresse IPv6]]
| J.Landru
| N. Benamar
|
|-
| [[MOOC:Séquence 13| Seq13: Adresses unicast]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 14|Seq14: Adresses multicast]]
| J.Landru
| B.DiGennaro
|
|-
| [[MOOC:Séquence 15|Seq15: Utilisation des adresses dans le réseau]]
| J.Landru
|N. Benamar
|
|-
| [[MOOC:Séquence 16|Seq16: Construction d'un plan d'adressage]]
| B.DiGennaro
| J.Landru
| N. Benamar
|-
! rowspan="6" | [[MOOC:Semaine 2|Semaine 2]]
| [[MOOC:Séquence 21|Seq21: L'entête IPv6]]
| JP.Rioual (?)
|
|
|-
| [[MOOC:Séquence 22|Seq22: L'encapsulation]]
| JP.Rioual (?)
|
|
|-
| [[MOOC:Séquence 23|Seq23: Routage statique]]
| JP.Rioual (?)
| R. Lorion
|
|-
| [[MOOC:Séquence 24|Seq24: Nouvelles fonctionnalités]]
| JP.Rioual (?)
|
|
|-
| [[MOOC:Séquence 25|Seq25: Taille du paquet]]
| JP.Rioual (?)
|
|
|-
| [[MOOC:Séquence 26|Seq26: Mise en oeuvre]]
| JP.Rioual
|
|
|-
! rowspan="5" | [[MOOC:Semaine 3|Semaine 3]]
| [[MOOC:Séquence 31|Seq31: Le contrôle d'IPv6 grâce à ICMPv6]]
| B.Joachim
|P. Anelli, R. Lorion
|
|-
| [[MOOC:Séquence 32|Seq32: L'autoconfiguration des paramètres]]
| B.Joachim
| JP Rioual
|
|-
| [[MOOC:Séquence 33|Seq33: DHCPv6 avec et sans état]]
| B.Joachim
|N. Benamar
|
|-
| [[MOOC:Séquence 34|Seq35: Le DNS]]
| B.Joachim
| N. Benamar
|
|-
| [[MOOC:Séquence 35|Seq36: Mise en oeuvre]]
|B.Joachim
| JP.Rioual
|
|-
! rowspan="6" | [[MOOC:Semaine 4|Semaine 4]]
| [[MOOC:Séquence 41|Seq41: La problématique de l'interopérabilité]]
| P.Anelli
|
|
|-
| [[MOOC:Séquence 42|Seq42: La double pile]]
| P.Anelli
| B.DiGennaro
|
|-
| [[MOOC:Séquence 43|Seq43: Tunnels]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 44|Seq44: Traduction d'adresses]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 45|Seq45: Passerelles applicatives]]
| P.Anelli, B.Stévant
| B.DiGennaro
|
|-
| [[MOOC:Séquence 46|Seq 46:Quelle solution choisir ?]]
| P.Anelli, B.Stévant
|
|
|}

MOOC:Matrice des séquences

2015-02-16T11:11:16Z

Nbenamar:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|gestion de projet]] > [[MOOC:Matrice_des_séquences| Matrice des séquences]]
----

{| border="1" cellpadding="10" cellspacing="0"
! colspan="2" | Séquences
! Intervenants
! Contributeurs
! Relecteurs
|-
! rowspan="6" | [[MOOC:Semaine 1|Semaine 1]]
| [[MOOC:Séquence 11|Seq11: Intro sur l'évolution de l'adressage]]
| J.landru
| N. Benamar
|
|-
| [[MOOC:Séquence 12|Seq 12: Notation d’une adresse IPv6]]
| J.Landru
| N. Benamar
|
|-
| [[MOOC:Séquence 13| Seq13: Adresses unicast]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 14|Seq14: Adresses multicast]]
| J.Landru
| B.DiGennaro
|
|-
| [[MOOC:Séquence 15|Seq15: Utilisation des adresses dans le réseau]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 16|Seq16: Construction d'un plan d'adressage]]
| B.DiGennaro
| J.Landru
|
|-
! rowspan="6" | [[MOOC:Semaine 2|Semaine 2]]
| [[MOOC:Séquence 21|Seq21: L'entête IPv6]]
|
|
|
|-
| [[MOOC:Séquence 22|Seq22: L'encapsulation]]
|
|
|
|-
| [[MOOC:Séquence 23|Seq23: Routage statique]]
|
|
|
|-
| [[MOOC:Séquence 24|Seq24: Nouvelles fonctionnalités]]
|
|
|
|-
| [[MOOC:Séquence 25|Seq25: Taille du paquet]]
|
|
|
|-
| [[MOOC:Séquence 26|Seq26: Mise en oeuvre]]
| JP.Rioual
|
|
|-
! rowspan="5" | [[MOOC:Semaine 3|Semaine 3]]
| [[MOOC:Séquence 31|Seq31: Le contrôle d'IPv6 grâce à ICMPv6]]
|
|P. Anelli
|
|-
| [[MOOC:Séquence 32|Seq32: L'autoconfiguration des paramètres]]
|
| JP Rioual
|
|-
| [[MOOC:Séquence 33|Seq33: DHCPv6 avec et sans état]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 34|Seq35: Le DNS]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 35|Seq36: Mise en oeuvre]]
|
| JP.Rioual, B.Joachim
|
|-
! rowspan="6" | [[MOOC:Semaine 4|Semaine 4]]
| [[MOOC:Séquence 41|Seq41: La problématique de l'interopérabilité]]
| P.Anelli
|
|
|-
| [[MOOC:Séquence 42|Seq42: La double pile]]
| P.Anelli
| B.DiGennaro
|
|-
| [[MOOC:Séquence 43|Seq43: Tunnels]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 44|Seq44: Traduction d'adresses]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 45|Seq45: Passerelles applicatives]]
| B.Stévant
| P.Anelli, B.DiGennaro
|
|-
| [[MOOC:Séquence 46|Seq 46:Quelle solution choisir ?]]
| B.Stévant
| P.Anelli
|
|}

MOOC:Matrice des séquences

2015-02-16T11:09:57Z

Nbenamar:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|gestion de projet]] > [[MOOC:Matrice_des_séquences| Matrice des séquences]]
----

{| border="1" cellpadding="10" cellspacing="0"
! colspan="2" | Séquences
! Intervenants
! Contributeurs
! Relecteurs
|-
! rowspan="6" | [[MOOC:Semaine 1|Semaine 1]]
| [[MOOC:Séquence 11|Seq11: Intro sur l'évolution de l'adressage]]
| J.landru
N. Benamar
|
|
|-
| [[MOOC:Séquence 12|Seq 12: Notation d’une adresse IPv6]]
| J.Landru
N. Benamar
|
|
|-
| [[MOOC:Séquence 13| Seq13: Adresses unicast]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 14|Seq14: Adresses multicast]]
| J.Landru
| B.DiGennaro
|
|-
| [[MOOC:Séquence 15|Seq15: Utilisation des adresses dans le réseau]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 16|Seq16: Construction d'un plan d'adressage]]
| B.DiGennaro
| J.Landru
|
|-
! rowspan="6" | [[MOOC:Semaine 2|Semaine 2]]
| [[MOOC:Séquence 21|Seq21: L'entête IPv6]]
|
|
|
|-
| [[MOOC:Séquence 22|Seq22: L'encapsulation]]
|
|
|
|-
| [[MOOC:Séquence 23|Seq23: Routage statique]]
|
|
|
|-
| [[MOOC:Séquence 24|Seq24: Nouvelles fonctionnalités]]
|
|
|
|-
| [[MOOC:Séquence 25|Seq25: Taille du paquet]]
|
|
|
|-
| [[MOOC:Séquence 26|Seq26: Mise en oeuvre]]
| JP.Rioual
|
|
|-
! rowspan="5" | [[MOOC:Semaine 3|Semaine 3]]
| [[MOOC:Séquence 31|Seq31: Le contrôle d'IPv6 grâce à ICMPv6]]
|
|P. Anelli
|
|-
| [[MOOC:Séquence 32|Seq32: L'autoconfiguration des paramètres]]
|
| JP Rioual
|
|-
| [[MOOC:Séquence 33|Seq33: DHCPv6 avec et sans état]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 34|Seq35: Le DNS]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 35|Seq36: Mise en oeuvre]]
|
| JP.Rioual, B.Joachim
|
|-
! rowspan="6" | [[MOOC:Semaine 4|Semaine 4]]
| [[MOOC:Séquence 41|Seq41: La problématique de l'interopérabilité]]
| P.Anelli
|
|
|-
| [[MOOC:Séquence 42|Seq42: La double pile]]
| P.Anelli
| B.DiGennaro
|
|-
| [[MOOC:Séquence 43|Seq43: Tunnels]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 44|Seq44: Traduction d'adresses]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 45|Seq45: Passerelles applicatives]]
| B.Stévant
| P.Anelli, B.DiGennaro
|
|-
| [[MOOC:Séquence 46|Seq 46:Quelle solution choisir ?]]
| B.Stévant
| P.Anelli
|
|}

MOOC:Matrice des séquences

2015-02-16T11:09:14Z

Nbenamar:

> [[MOOC:Accueil|MOOC]]>[[MOOC:Gestion_de_projet|gestion de projet]] > [[MOOC:Matrice_des_séquences| Matrice des séquences]]
----

{| border="1" cellpadding="10" cellspacing="0"
! colspan="2" | Séquences
! Intervenants
! Contributeurs
! Relecteurs
|-
! rowspan="6" | [[MOOC:Semaine 1|Semaine 1]]
| [[MOOC:Séquence 11|Seq11: Intro sur l'évolution de l'adressage]]
| J.landru N. Benamar
|
|
|-
| [[MOOC:Séquence 12|Seq 12: Notation d’une adresse IPv6]]
| J.Landru N. Benamar
|
|
|-
| [[MOOC:Séquence 13| Seq13: Adresses unicast]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 14|Seq14: Adresses multicast]]
| J.Landru
| B.DiGennaro
|
|-
| [[MOOC:Séquence 15|Seq15: Utilisation des adresses dans le réseau]]
| J.Landru
|
|
|-
| [[MOOC:Séquence 16|Seq16: Construction d'un plan d'adressage]]
| B.DiGennaro
| J.Landru
|
|-
! rowspan="6" | [[MOOC:Semaine 2|Semaine 2]]
| [[MOOC:Séquence 21|Seq21: L'entête IPv6]]
|
|
|
|-
| [[MOOC:Séquence 22|Seq22: L'encapsulation]]
|
|
|
|-
| [[MOOC:Séquence 23|Seq23: Routage statique]]
|
|
|
|-
| [[MOOC:Séquence 24|Seq24: Nouvelles fonctionnalités]]
|
|
|
|-
| [[MOOC:Séquence 25|Seq25: Taille du paquet]]
|
|
|
|-
| [[MOOC:Séquence 26|Seq26: Mise en oeuvre]]
| JP.Rioual
|
|
|-
! rowspan="5" | [[MOOC:Semaine 3|Semaine 3]]
| [[MOOC:Séquence 31|Seq31: Le contrôle d'IPv6 grâce à ICMPv6]]
|
|P. Anelli
|
|-
| [[MOOC:Séquence 32|Seq32: L'autoconfiguration des paramètres]]
|
| JP Rioual
|
|-
| [[MOOC:Séquence 33|Seq33: DHCPv6 avec et sans état]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 34|Seq35: Le DNS]]
| B.Joachim
|
|
|-
| [[MOOC:Séquence 35|Seq36: Mise en oeuvre]]
|
| JP.Rioual, B.Joachim
|
|-
! rowspan="6" | [[MOOC:Semaine 4|Semaine 4]]
| [[MOOC:Séquence 41|Seq41: La problématique de l'interopérabilité]]
| P.Anelli
|
|
|-
| [[MOOC:Séquence 42|Seq42: La double pile]]
| P.Anelli
| B.DiGennaro
|
|-
| [[MOOC:Séquence 43|Seq43: Tunnels]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 44|Seq44: Traduction d'adresses]]
| P.Anelli
| J.Landru
|
|-
| [[MOOC:Séquence 45|Seq45: Passerelles applicatives]]
| B.Stévant
| P.Anelli, B.DiGennaro
|
|-
| [[MOOC:Séquence 46|Seq 46:Quelle solution choisir ?]]
| B.Stévant
| P.Anelli
|
|}

MOOC:Sequence 2-d

2015-02-02T10:16:13Z

Nbenamar: /* Ressources */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]] >Semaine 1
----
= Thème: Adressage =

== Objectifs Pédagogiques ==
Note : se limiter aux niveaux 1, 2, 3 voir 4 selon la [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom]

Niveau 1 : Se familiariser avec les adresses IPv6.
* Définir une adresse IPv6, son utilité, ses caractéristiques
* Décrire la notation d'une adresse IPv6
* Nommer les différents types d'adresses IPv6 (la notion de portée d'adresse (scope))
* Identifier le type d'une adresse IPv6 quelconque
*

Niveau 2 : Comprendre ce qui constitue une adresse IPv6.
* Expliquer les rôles des identifiants de réseau et d'interface dans une adresse unicast
* Décrire les différents mécanismes de création d'un identifiant d'interface
* Comprendre l'utilité des adresses unicast temporaires
*

Niveau 3 : Planifier l'adressage IPv6 dans un réseau
* Choisir un plan d'adressage pour un scénario de réseau donné
* Démontrer la pertinence d'un plan d'adressage et de ses évolutions
*

Niveau 4 : Analyser l'impact de l'adressage IPv6
* Démontrer qu'un plan d'adressage IPv6 supporte les évolutions du réseau

== Structure du cours ==

=== [[MOOC:Séquence 11]] Intro sur l'évolution de l'adressage ===
* IPv4 pas extensible
* Nouveaux besoins
* Conserver les usages de déploiement (adresses privées)
* Déplacer la complexité aux extrémités

=== [[MOOC:Séquence 12]] Notation d’une adresse IPv6 ===
* Notation hexadécimale
* Notation CIDR

=== [[MOOC:Séquence 13]] Adresses unicast ===
* Unicast = une machine
* Séparation Réseau / IID
* Unicast global
* Lien local
* Unicast local (NAT66?)

=== [[MOOC:Séquence 14]] Adresses Multicast ===
* Multicast = un groupe de machine
* Pas de broadcast en IPv6
* Portée du multicast
* Focus sur le multicast lien local

=== [[MOOC:Séquence 15]] Utilisation des adresses dans le réseau ===
* Les adresses unicast sur une interface réseau (+temporaires)
* Les préfixes dans une table de routage
* Les groupes multicast

=== [[MOOC:Séquence 16]] Construction d'un plan d'adressage ===

== Ressources ==

Du G6
* Livre chapitre : [[Adressage_multicast]]
* Support (extraits en PDF)

Web

. http://www.cbtnuggets.com/it-training-videos/course/cbtn_ipv6 (Vidéos comprehensives mais non-gratuites de Keith )
. https://www.youtube.com/channel/UCrCh8p6p2UZC18vqSBhN_sA (chaîne Youtube de Keith)
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08 IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]
. http://www.cabrillo.edu/~rgraziani/ipv6.html (Un des meilleurs sites dédié à IPv6)

Formulaires (l'essentiel sur une page)
* http://teachmeipv6.com/IPv6-Essentials-Cheat-Sheet_v1.1.pdf
* http://packetlife.net/media/library/8/IPv6.pdf

===Documents de référence===
Référence <strike>barrée</strike> si reprise dans une séquence

* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
* RFC 7346 IPv6 Multicast Address Scopes
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
* RFC 6752 Issues with Private IP Addressing in the Internet
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
* <strike>RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])</strike>
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])

===Activités===

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-TD-intro.pdf TD Adressage] de P. Anelli
* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/2-TD-intro.pdf TD Adressage suite] de P. Anelli

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-decouverte.pdf TP découverte] de P. Anelli
* [http://wikitp.rennes.telecom-bretagne.eu/index.php/IPv6_catalyst TP IPv6 : Déploiement et Intégration] à Télécom Bretagne

MOOC:Sequence 2-d

2015-02-02T10:14:50Z

Nbenamar: /* Ressources */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]] >Semaine 1
----
= Thème: Adressage =

== Objectifs Pédagogiques ==
Note : se limiter aux niveaux 1, 2, 3 voir 4 selon la [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom]

Niveau 1 : Se familiariser avec les adresses IPv6.
* Définir une adresse IPv6, son utilité, ses caractéristiques
* Décrire la notation d'une adresse IPv6
* Nommer les différents types d'adresses IPv6 (la notion de portée d'adresse (scope))
* Identifier le type d'une adresse IPv6 quelconque
*

Niveau 2 : Comprendre ce qui constitue une adresse IPv6.
* Expliquer les rôles des identifiants de réseau et d'interface dans une adresse unicast
* Décrire les différents mécanismes de création d'un identifiant d'interface
* Comprendre l'utilité des adresses unicast temporaires
*

Niveau 3 : Planifier l'adressage IPv6 dans un réseau
* Choisir un plan d'adressage pour un scénario de réseau donné
* Démontrer la pertinence d'un plan d'adressage et de ses évolutions
*

Niveau 4 : Analyser l'impact de l'adressage IPv6
* Démontrer qu'un plan d'adressage IPv6 supporte les évolutions du réseau

== Structure du cours ==

=== [[MOOC:Séquence 11]] Intro sur l'évolution de l'adressage ===
* IPv4 pas extensible
* Nouveaux besoins
* Conserver les usages de déploiement (adresses privées)
* Déplacer la complexité aux extrémités

=== [[MOOC:Séquence 12]] Notation d’une adresse IPv6 ===
* Notation hexadécimale
* Notation CIDR

=== [[MOOC:Séquence 13]] Adresses unicast ===
* Unicast = une machine
* Séparation Réseau / IID
* Unicast global
* Lien local
* Unicast local (NAT66?)

=== [[MOOC:Séquence 14]] Adresses Multicast ===
* Multicast = un groupe de machine
* Pas de broadcast en IPv6
* Portée du multicast
* Focus sur le multicast lien local

=== [[MOOC:Séquence 15]] Utilisation des adresses dans le réseau ===
* Les adresses unicast sur une interface réseau (+temporaires)
* Les préfixes dans une table de routage
* Les groupes multicast

=== [[MOOC:Séquence 16]] Construction d'un plan d'adressage ===

== Ressources ==

Du G6
* Livre chapitre : [[Adressage_multicast]]
* Support (extraits en PDF)

Web
. http://www.cbtnuggets.com/it-training-videos/course/cbtn_ipv6 (Vidéos comprehensives mais non-gratuites de Keith )
https://www.youtube.com/channel/UCrCh8p6p2UZC18vqSBhN_sA (chaîne Youtube de Keith)
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08 IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]
. http://www.cabrillo.edu/~rgraziani/ipv6.html (Un des meilleurs sites dédié à IPv6)

Formulaires (l'essentiel sur une page)
* http://teachmeipv6.com/IPv6-Essentials-Cheat-Sheet_v1.1.pdf
* http://packetlife.net/media/library/8/IPv6.pdf

===Documents de référence===
Référence <strike>barrée</strike> si reprise dans une séquence

* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
* RFC 7346 IPv6 Multicast Address Scopes
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
* RFC 6752 Issues with Private IP Addressing in the Internet
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
* <strike>RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])</strike>
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])

===Activités===

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-TD-intro.pdf TD Adressage] de P. Anelli
* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/2-TD-intro.pdf TD Adressage suite] de P. Anelli

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-decouverte.pdf TP découverte] de P. Anelli
* [http://wikitp.rennes.telecom-bretagne.eu/index.php/IPv6_catalyst TP IPv6 : Déploiement et Intégration] à Télécom Bretagne

MOOC:Sequence 2-d

2015-01-27T21:31:26Z

Nbenamar: /* Ressources */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]] >Semaine 1
----
= Thème: Adressage =

== Objectifs Pédagogiques ==
Note : se limiter aux niveaux 1, 2, 3 voir 4 selon la [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom]

Niveau 1 : Se familiariser avec les adresses IPv6.
* Définir une adresse IPv6, son utilité, ses caractéristiques
* Décrire la notation d'une adresse IPv6
* Nommer les différents types d'adresses IPv6 (la notion de portée d'adresse (scope))
* Identifier le type d'une adresse IPv6 quelconque
*

Niveau 2 : Comprendre ce qui constitue une adresse IPv6.
* Expliquer les rôles des identifiants de réseau et d'interface dans une adresse unicast
* Décrire les différents mécanismes de création d'un identifiant d'interface
* Comprendre l'utilité des adresses unicast temporaires
*

Niveau 3 : Planifier l'adressage IPv6 dans un réseau
* Choisir un plan d'adressage pour un scénario de réseau donné
* Démontrer la pertinence d'un plan d'adressage et de ses évolutions
*

Niveau 4 : Analyser l'impact de l'adressage IPv6
* Démontrer qu'un plan d'adressage IPv6 supporte les évolutions du réseau

== Structure du cours ==

=== Intro sur l'évolution de l'adressage ===
* IPv4 pas extensible
* Nouveaux besoins
* Conserver les usages de déploiement (adresses privées)
* Déplacer la complexité aux extrémités

=== Notation d’une adresse IPv6 ===
* Notation hexadécimale
* Notation CIDR

=== Adresses unicast ===
* Unicast = une machine
* Séparation Réseau / IID
* Unicast global
* Lien local
* Unicast local (NAT66?)

=== Adresses Multicast ===
* Multicast = un groupe de machine
* Pas de broadcast en IPv6
* Portée du multicast
* Focus sur le multicast lien local

=== Utilisation des adresses dans le réseau ===
* Les adresses unicast sur une interface réseau (+temporaires)
* Les préfixes dans une table de routage
* Les groupes multicast

=== Construction d'un plan d'adressage ===

== Séquences ==

* [[MOOC:Séquence 11]] Intro : l'évolution nécessaire de l'espace d'adressage
* [[MOOC:Séquence 12]] Notation d'une adresse IPv6
* [[MOOC:Séquence 13]] Les adresses unicast
* [[MOOC:Séquence 14]] Les adresses multicast
* [[MOOC:Séquence 15]] Utilisation des adresses dans le réseau
* [[MOOC:Séquence 16]] Lab : Construction du plan d'adressage

== Ressources ==

Du G6
* Livre chapitre : [[Adressage_multicast]]
* Support (extraits en PDF)

Web
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08 IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]
. http://www.cabrillo.edu/~rgraziani/ipv6.html (Un des meilleurs sites dédié à IPv6)

Formulaires (l'essentiel sur une page)
* http://teachmeipv6.com/IPv6-Essentials-Cheat-Sheet_v1.1.pdf
* http://packetlife.net/media/library/8/IPv6.pdf

===Documents de référence===
* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
* RFC 7346 IPv6 Multicast Address Scopes
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
* RFC 6752 Issues with Private IP Addressing in the Internet
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
* RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])

===Activités===

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-TD-intro.pdf TD Adressage] de P. Anelli
* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/2-TD-intro.pdf TD Adressage suite] de P. Anelli

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-decouverte.pdf TP découverte] de P. Anelli
* [http://wikitp.rennes.telecom-bretagne.eu/index.php/IPv6_catalyst TP IPv6 : Déploiement et Intégration] à Télécom Bretagne

MOOC:Sequence 2-d

2015-01-27T21:27:29Z

Nbenamar: /* Objectifs Pédagogiques */

> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]] >Semaine 1
----
= Thème: Adressage =

== Objectifs Pédagogiques ==
Note : se limiter aux niveaux 1, 2, 3 voir 4 selon la [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom]

Niveau 1 : Se familiariser avec les adresses IPv6.
* Définir une adresse IPv6, son utilité, ses caractéristiques
* Décrire la notation d'une adresse IPv6
* Nommer les différents types d'adresses IPv6 (la notion de portée d'adresse (scope))
* Identifier le type d'une adresse IPv6 quelconque
*

Niveau 2 : Comprendre ce qui constitue une adresse IPv6.
* Expliquer les rôles des identifiants de réseau et d'interface dans une adresse unicast
* Décrire les différents mécanismes de création d'un identifiant d'interface
* Comprendre l'utilité des adresses unicast temporaires
*

Niveau 3 : Planifier l'adressage IPv6 dans un réseau
* Choisir un plan d'adressage pour un scénario de réseau donné
* Démontrer la pertinence d'un plan d'adressage et de ses évolutions
*

Niveau 4 : Analyser l'impact de l'adressage IPv6
* Démontrer qu'un plan d'adressage IPv6 supporte les évolutions du réseau

== Structure du cours ==

=== Intro sur l'évolution de l'adressage ===
* IPv4 pas extensible
* Nouveaux besoins
* Conserver les usages de déploiement (adresses privées)
* Déplacer la complexité aux extrémités

=== Notation d’une adresse IPv6 ===
* Notation hexadécimale
* Notation CIDR

=== Adresses unicast ===
* Unicast = une machine
* Séparation Réseau / IID
* Unicast global
* Lien local
* Unicast local (NAT66?)

=== Adresses Multicast ===
* Multicast = un groupe de machine
* Pas de broadcast en IPv6
* Portée du multicast
* Focus sur le multicast lien local

=== Utilisation des adresses dans le réseau ===
* Les adresses unicast sur une interface réseau (+temporaires)
* Les préfixes dans une table de routage
* Les groupes multicast

=== Construction d'un plan d'adressage ===

== Séquences ==

* [[MOOC:Séquence 11]] Intro : l'évolution nécessaire de l'espace d'adressage
* [[MOOC:Séquence 12]] Notation d'une adresse IPv6
* [[MOOC:Séquence 13]] Les adresses unicast
* [[MOOC:Séquence 14]] Les adresses multicast
* [[MOOC:Séquence 15]] Utilisation des adresses dans le réseau
* [[MOOC:Séquence 16]] Lab : Construction du plan d'adressage

== Ressources ==

Du G6
* Livre chapitre : [[Adressage_multicast]]
* Support (extraits en PDF)

Web
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08 IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]

Formulaires (l'essentiel sur une page)
* http://teachmeipv6.com/IPv6-Essentials-Cheat-Sheet_v1.1.pdf
* http://packetlife.net/media/library/8/IPv6.pdf

===Documents de référence===
* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
* RFC 7346 IPv6 Multicast Address Scopes
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
* RFC 6752 Issues with Private IP Addressing in the Internet
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
* RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])

===Activités===

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-TD-intro.pdf TD Adressage] de P. Anelli
* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/2-TD-intro.pdf TD Adressage suite] de P. Anelli

* [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/1-IPv6_TP-decouverte.pdf TP découverte] de P. Anelli
* [http://wikitp.rennes.telecom-bretagne.eu/index.php/IPv6_catalyst TP IPv6 : Déploiement et Intégration] à Télécom Bretagne