L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 2462, n'a pas prévu de mécanisme de découverte automatique de la liste des serveurs DNS récursifs (cache). En revanche, il était prévu que ces informations complémentaires soient fournies par l'autoconfiguration avec état. Les spécifications du protocole d'autoconfiguration avec état, DHCPv6, ont mis longtemps (six ans environ) à passer en RFC (RFC 3315) et le besoin de découverte des serveurs DNS récursifs s'est accentué davantage. En effet, afin de renforcer le déploiement d'IPv6, la communauté IPv6 s'est vite trouvée dans l'urgence de mettre en oeuvre un mécanisme de découverte automatique du DNS avec ou sans DHCPv6 (qui était justement près de sortir).

Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop ». C'est le groupe dnsop qui a pris en charge les débats sur ces propositions. Le niveau de maturité et de stabilité (en termes de discussions et d'implémentations) est variable d'une proposition à l'autre. À ce jour, et après de longs débats, aucun consensus n'a encore été trouvé pour adopter la meilleure solution (s'il y en a). En revanche, les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation [Jeong-id]. Ce document, qui a déjà acquis une certaine stabilité , donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.

Voici maintenant un résumé des trois propositions :

• Proposition 1 : mécanisme à base de DHCP : deux solutions légèrement différentes ont été proposées. Elles proposent toutes les deux d'utiliser la même option DHCPv6 DNS Recursive Name Server spécifiée dans le RFC 3646 :
  • découverte via un serveur DHCPv6 complet (RFC 3315 : c'est-à-dire qui alloue dynamiquement les adresses IPv6 ;
  • découverte du DNS via un serveur DHCPv6-lite (RFC 3736) : celui-ci n'alloue pas d'adresses IPv6 mais il est simplement chargé d'informer les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression, ...) ;
  • Dans les deux cas, si l'équipement est en double pile et s'il est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), il faut définir une politique d'arbitrage entre les deux listes de serveurs DNS récursifs obtenues si celles-ci sont incohérentes ;
• Proposition 2 : mécanisme à base d'annonce de routeur (RA) [Jeong-id] : cette proposition apporte un complément à l'autoconfiguration sans état (RFC 2462) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 2461) par l'information DNS nécessaire ;
• Proposition 3 : mécanisme à base d'adresses anycast bien connues (Well-known anycast addresses) : trois adresses IPv6 anycast (et trois autres en IPv4) qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement.

En attendant l'avancement et la publication en RFC du document [Jeong-id] synthétisant les approches décrites ci-dessus, la liste des serveurs DNS récursifs est généralement configurée aujourd'hui selon l'une des trois méthodes suivantes :

• par configuration manuelle (en éditant le fichier /etc/resolv.conf par exemple pour les systèmes Unix) sur les équipements ne supportant qu'IPv6 ou en l'absence de serveur DHCP ;
• par configuration automatique via DHCPv4 pour les équipements en double pile IPv4/IPv6 lorsqu'un serveur DHCPv4 est disponible.
• Par configuration automatique via DHCPv6 pour les environnements où une implémentation de DHCPv6 (avec l'option de découverte de DNS) est disponible.