Pour lancer les tests qui vont suivre, il est nécessaire que votre système dispose d'IPv6, et certains exemples montrent des adresses ne pouvant être atteintes que si une connexion au 6bone est disponible.
A cause des mises à jour de sécurité ces dernières années, tout serveur du Système des Noms de Domaine (DNS) devrait fonctionner avec un logiciel récent comprenant déjà le type (intermédiaire) d'adresse IPv6 AAAA (le nouveau, nommé A6 n'est pas encore assez répandu pour le moment, car uniquement supporté par BIND9 et supérieurs, mais aussi à cause de la non existence de support du domaine racine IP6.ARPA). Un simple test pour savoir si le système utilisé peut résoudre les adresses IPv6 est
# host -t AAAA www.join.uni-muenster.de |
et cela devrait affiché quelque chose comme ce qui suit:
www.join.uni-muenster.de. is an alias for tolot.join.uni-muenster.de. tolot.join.uni-muenster.de. has AAAA address 2001:638:500:101:2e0:81ff:fe24:37c6 |
Des clients telnet prêts pour IPv6 sont disponibles. Un simple test peut être effectué par
$ telnet 3ffe:400:100::1 80 Trying 3ffe:400:100::1... Connected to 3ffe:400:100::1. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 16 Dec 2001 16:07:21 GMT Server: Apache/2.0.28 (Unix) Last-Modified: Wed, 01 Aug 2001 21:34:42 GMT ETag: "3f02-a4d-b1b3e080" Accept-Ranges: bytes Content-Length: 2637 Connection: close Content-Type: text/html; charset=ISO-8859-1 Connection closed by foreign host. |
Si le client telnet ne comprend pas l'adresse IPv6 et dit quelque chose comme ”ne peut résoudre le nom d'hôte” (”cannot resolve hostname”), IPv6 n'est alors pas disponible.
Les versions actuelles d'openssh sont prêtes pour IPv6. Selon la configuration précédant la compilation, il y a deux comportements possibles.
--without-ipv4-default: le client essaie automatiquement une connexion IPv6 en premier et revient à IPv4 en cas d'échec.
--with-ipv4-default: la connexion par défaut est IPv4, la connexion IPv6 doit être forcée comme dans l'exemple qui suit:
$ ssh -6 ::1 user@::1's password: ****** [user@ipv6host user]$ |
Si votre client ssh ne comprend pas l'option ”-6”, c'est qu'il n'a pas IPv6 de disponible, comme la plupart des paquetages de ssh version 1.
Le client et le serveur SSH de chez SSH.com sont aussi prêts pour IPv6, et gratuits pour les machines Linux et FreeBSD selon l'usage - commercial ou personnel - qui en est fait.
L'état actuel de la liste des navigateurs web IPv6 est disponible.
La plupart ont des problèmes irrésolues pour le moment
Si un seul proxy IPv4 est utilisé dans les réglages, les requêtes IPv6 seront bien envoyées vers le proxy, mais celui-ci échouera à comprendre la requête, laquelle échouera. Solution: mettre à jour le logiciel proxy (à voir plus tard).
Les réglages de configuration automatique de proxy (*.pac) ne peuvent être étendus afin de prendre en charge différemment les requêtes IPv6 (par exemple ne pas utiliser le proxy) à cause de leur nature (écrits en Java-script et bien encodés en dur dans les sources, comme cela peut être observé pour le code source de Maxilla).
C'est ainsi que les anciennes versions ne comprennent pas un URL avec une adresse encodée en IPv6 comme http://[2a01:238:4281:8600:812a:5915:8d24:58f3]/ (cet URL ne fonctionne qu'avec un navigateur disposant d'IPv6!).
Un bref test est d'essayer l'URL fourni avec un navigateur donné, sans utiliser de proxy.
Un bon point de départ pour tester la navigation IPv6 est http://www.kame.net/. Si la tortue sur la page est animée, la connexion se fait via IPv6, sinon la tortue est statique.
| Précédent | Sommaire | Suivant |
| Les programmes prêts pour IPv6 | Niveau supérieur | Les programmes serveur prêts pour IPv6 |