Nous sommes déjà assez rompus aux protocoles de l'internet. Même si nous ne les manipulons qu'au travers d'IPv4, nous ne somme plus des « newbies », nous savons que la configuration IP n'est pas miraculeuse, que nous avons besoin, en plus d'une adresse IP, de quelques renseignements supplémentaires pour pouvoir exploiter les ressources de l'internet :

• une adresse de passerelle par défaut ;
• au moins une adresse de DNS pour résoudre les noms en adresses IP.

Avec IPv4, ces informations nous sont communiquées par le fournisseur d'accès de façon automatique. Par DHCP si le processus de connexion est assimilé à une connexion sur un réseau local (cas de Free), ou par PPP(oE) lors de l'identification RADIUS. mais qu'en est-il en IPv6 ?

Il existe bien un RFC décrivant un protocole DHCPv6, mais il reste pour l'heure (où ces lignes sont écrites) expérimental. Nous avons vu que le mécanisme d'auto-configuration était privilégié pour l'obtention de son adresse IP. Ici, donc, foin de DHCP. Mais alors, comment notre machine a-t-elle fait pour découvrir l'adresse de la passerelle par défaut ? car nous avons vu sur la page précédente que cette adresse était bien connue.

Auto-configuration, soit. Mais comment notre système fait-il pour connaître le préfixe que nous attribue notre fournisseur d'accès ?

Disposons-nous d'une adresse de DNS IPv6 ? Et d'abord, comment fonctionne DNS en IPv6 ?

Il y a déjà longtemps que les DNS (Bind en particulier) savent diffuser à leurs clients aussi bien des adresses IPv4 que des adresses IPv6, pour un nom d'hôte donné. Exemple :

~# host www.kame.net
www.kame.net has address 203.178.141.194
www.kame.net has IPv6 address 2001:200:0:8002:203:47ff:fea5:3085

Pour ne pas trop vous donner le vertige, n'entrons pas de suite dans les détails de la manip. Disons simplement pour l'instant qu'il est possible de :

• demander à un DNS l'adresse IPv6 d'un hôte en l'interrogeant sur son IPv4 ;
• demander à un DNS l'adresse IPv4 d'un hôte en l'interrogeant sur son adresse IPv6 (si le DNS dispose d'une adresse IPv6 bien sûr).

En réalité, un DNS dispose :

• du champ « A » pour enregistrer l'IPv4 correspondant à un nom d'hôte ;
• du champ « AAAA » pour enregistrer l'IPv6 correspondant à un nom d'hôte.

Si le DNS en question dispose d'une adresse IPv4 et d'une adresse IPv6, les clients pourront l'interroger en IPv4 comme en IPv6 pour obtenir le champ A comme le champ AAAA pour un hôte donné.

Autrement dit, un DNS est capable de fournir des adresses IPv4 comme IPv6 pourvu qu'il les connaisse et ce, qu'il soit interrogé aussi bien par une requête IPv4 qu'une requête IPv6.

Comment connaître les adresses IP (v4 comme v6) des DNS que Free met à la disposition de ses clients ?

Les adresses IPv4 sont assez simples à retrouver, puisqu'elles figurent dans les informations fournies par DHCP, que nous trouvons sur notre Debian dans /var/lib/dhcp/dhclient.eth0.leases :

lease {
  interface "eth0";
...
  option domain-name-servers 212.27.54.252,212.27.53.252;
...
}

Nous avons donc deux DNS identifiés par leur IPv4:

• 212.27.54.252 ;
• 212.27.53.252.

Les adresses IPv6 sont elles aussi assez simples à trouver si l'on sait comment faire, mais pour l'instant, nous ne savons pas encore. Il vous faudra donc vous contenter de me croire sur parole :

• 2a01:5d8:e0ff::2 ;
• 2a01:5d8:e0ff::1.

Nous allons interroger ces DNS en mode IPv4 et en mode IPv6 à propos de www.kame.net et comparer les résultats :

~$ host -4 www.kame.net 212.27.54.252
Using domain server:
Name: 212.27.54.252
Address: 212.27.54.252#53
Aliases: 

www.kame.net has address 203.178.141.194
www.kame.net has IPv6 address 2001:200:0:8002:203:47ff:fea5:3085


~$ host -6 www.kame.net 2a01:5d8:e0ff::2
Using domain server:
Name: 2a01:5d8:e0ff::2
Address: 2a01:5d8:e0ff::2#53
Aliases: 

www.kame.net has address 203.178.141.194
www.kame.net has IPv6 address 2001:200:0:8002:203:47ff:fea5:3085

Quel que soit le serveur interrogé, en mode IPv4 comme en mode IPv6, nous obtenons bien les adresses IPv4 et IPv6 de la cible.

Bon. Mais comment notre système fait-il pour connaître la ou les adresses de DNS que notre fournisseur nous procure ?

Il existe une trousse à outils nommée ndisc6 (IPv6 diagnostic tools for Linux and BSD), facile à installer sur Debian, Ubuntu et dérivées par un aptitude install ndisc6. Bien entendu, les autres distributions récentes proposent également cette trousse, qui contient quatre outils de base.

Dans un premier temps, nous nous contenterons d'utiliser ces outils, sans trop savoir comment ils fonctionnent, juste pour voir les informations que l'on peut en tirer.

Permet de lancer une « découverte des voisins ». Comparable à la commande arping du monde IPv4. Utilisons cet outil pour scruter notre passerelle par défaut. Commençons par son adresse de type lien local, telle que nous l'avons découverte avec la commande route -A inet6 :

:~$ ndisc6 fe80::207:cbff:fe1f:f5a eth0
Solicitation de fe80::207:cbff:fe1f:f5a (fe80::207:cbff:fe1f:f5a) sur eth0...
Adresse cible de lien    : 00:07:CB:1F:0F:5A
 de fe80::207:cbff:fe1f:f5a

~$ ndisc6 2a01:5d8:52f3:500d::1 eth0
Solicitation de 2a01:5d8:52f3:500d::1 (2a01:5d8:52f3:500d::1) sur eth0...
Adresse cible de lien    : 00:07:CB:1F:0F:5A
 de 2a01:5d8:52f3:500d::1

Ne nous éternisons pas sur cet outil qui pour l'instant ne nous apprend rien de bien nouveau. En gros, un ping6 suivi d'un ip -6 neigh show nous en apprend tout autant.

Cet outil est magique. Voyons tout de suite ce qu'il est capable de nous apprendre :

~$ rdisc6 eth0
Solicitation de ff02::2 (ff02::2) sur eth0...

Limite de saut (TTL)      :           64 (      0x40)
Conf. d'adresse par DHCP  :          Non
Autres réglages par DHCP  :          Non
Préférence du routeur     :        moyen
Durée de vie du routeur   :         1800 (0x00000708) secondes
Temps d'atteinte          :  non indiqué (0x00000000)
Temps de retransmission   :  non indiqué (0x00000000)
 Préfixe                  : 2a01:5d8:52f3:500d::/64
  Durée de validité       :        86400 (0x00015180) secondes
  Durée de préférence     :        86400 (0x00015180) secondes
 Recursive DNS server     : 2a01:5d8:e0ff::2
 Recursive DNS server     : 2a01:5d8:e0ff::1
  DNS servers lifetime    :          600 (0x00000258) secondes
 MTU                      :         1480 octets (valide)
 Adresse source de lien   : 00:07:CB:1F:0F:5A
 de fe80::207:cbff:fe1f:f5a

Là, nous sommes servis. Nous apprenons que :

• il n'y a pas de DHCP dans le coup ;
• le préfixe qui nous est attribué est bien 2a01:5d8:52f3:500d::/64 ;
• les durées de validité et de préférence sont identiques et de 86400 secondes (24 heures) ;
• les DNS proposés sont 2a01:5d8:e0ff::2 et 2a01:5d8:e0ff::1 ;
• le routeur (passerelle par défaut) est fe80::207:cbff:fe1f:f5a.

Nous sentons bien ici qu'il faudra approfondir cette question. Nous avons récupéré toutes les informations nécessaires, comme nous l'aurions fait en IPv4 par DHCP, mais ici, ce n'est pas DHCP. Alors, qu'est-ce que c'est ?

De plus, que représente cette adresse ff02::2 qui semble être la source de toutes ces informations ?

Comme son nom l'indique, cette commande est équivalente au tcptraceroute du monde IPv4 :

:~$ tcptraceroute6  www.kame.net
traceroute vers orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) de 2a01:5d8:52f3:500d:21b:11ff:fe52:bfab, port 80, du port 56328, 30 sauts max, 60 octet/paquet
 1  2a01:5d8:52f3:500d::1 (2a01:5d8:52f3:500d::1)  0.586 ms  0.493 ms  0.514 ms 
 2  2a01:5d8:e000:9d1::4 (2a01:5d8:e000:9d1::4)  48.728 ms  48.941 ms  48.161 ms 
 3  2a01:5d8:e000:9d1::fe (2a01:5d8:e000:9d1::fe)  50.412 ms  49.901 ms  *
...
22  lo0.alaxala1.k2.wide.ad.jp (2001:200:0:4800::7800:1)  342.425 ms  342.790 ms  339.848 ms 
23  orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085)  343.017 ms [ouvert]  342.494 ms  338.770 ms 

Comme vous le constatez, il n'y a rien de fondamentalement nouveau, si ce n'est que nous évoluons dans un monde IPv6.

• le « hop » 1 nous confirme une fois encore l'adresse IP (globale) de notre passerelle par défaut ;
• le « hop » 22 nous apprend que la cible www.kame.net se situe au japon et que son port 80 est ouvert.

Nous n'allons pas nous intéresser à cette commande, qui est équivalente au traceroute du monde IPv4 et qui ne nous apprendra rien de plus ici.

Le lecteur attentif aura pu constater que cette page pose beaucoup de question, mais n'apporte guère de réponses sur les mécanismes mis en œuvre, signe évident qu'il y a encore de la lecture en perspective…

Si nous avons appris qu'il existe un mécanisme qui remplace DHCP, nous ne savons toujours pas exactement lequel. Ami lecteur, ne rate surtout pas la page suivante, qui va enfin commencer à répondre à ces questions.