l'option RDNSS a été ajoutée au RA apres dans une autre RFC. Ca date pas de la meme epoque et des memes personnes.

elle n'est pas supportée partout et beaucoup de gens n'y adhérent pas.

Les stack IP sont du code hypercritique qu'on ne change pas comme ca sur un coup de tete parce qu'un type a pondu une rfc ou parce que Free a decidé de mettre cette option dans sa box.

l'option RDNSS a été ajoutée au RA apres dans une autre RFC. Ca date pas de la meme epoque et des memes personnes.

elle n'est pas supportée partout et beaucoup de gens n'y adhérent pas.

Les stack IP sont du code hypercritique qu'on ne change pas comme ca sur un coup de tete parce qu'un type a pondu une rfc ou parce que Free a decidé de mettre cette option dans sa box.

La RFC 4861 de 2007 définis les RA (remplaçant la RFC 2461 de 1998 elle-même remplaçant la RFC 1970 de 1996) et la RFC 6106 de 2010 (remplaçant la RFC 5006 de 2007) l'option DNS dans les RA.
Le besoin de deux services (un èmetteur de RA ICMPv6 et un serveur DHCPv6) uniquement pour fournir les adresses DNS aux systèmes finaux est du gaspillage de ressource et de la complexité inutile d'administration.
Comme la RFC 4861 précise que toute option non reconnu doit être ignoré tout en continuant l’interprétation du paquet, rajouter cette option était le plus simple.

La plupart des OS (sauf Windows NT) supportent désormais cette option et je pense que ce support viendra.

Il faut pas généraliser a la planète entière ce qui marche bien sur un petit réseau constitué de la box d'un FAI et de quelques ordis.

Le fait est que ces considérations DHCP vs RA pour le DNS en v6 datent de bien longtemps, au moins 2006 si c'est pas avant.
je vous invite a lire en entier la RFC 4339 qui détaille les + et - de chaque système.

Ca vous evitera d'avoir des avis aussi tranchés que 'débile', " gaspillage de ressource et de la complexité inutile d'administration" car

le fait est qu'aujourd'hui en 2013 qu'entres autres, ni Microsoft ni Cisco, ne supportent toujours pas le RDNSS.
le fait est que des gens bien informés recommandent toujours d'avoir DHCP pour les routeurs style Freebox (voir RFC 6204 section 4.3, L-8: MUST pour DHCP, L-11: SHOULD pour RDNSS).

Personnellement j'ai pas d'avis aussi tranché, ce qui me gène énormèment c'est qu'on ait 2 méthodes au lieu d'en avoir qu'une. c'est ça le problème majeur dans cette histoire et source future de beaucoup de problèmes et confusions.

j'ai une préférence pour DHCP parce que l'on connait deja ca en v4 et ca parait plus logique en terme de 'couches réseaux'.
En fait le 'stateless dhcp' me parait le meilleurs compris dans l'histoire mais c'est que mon avis: tout ce qui concerne la couche 3 c'est RD/RA (ip, passerelle) et tout le reste c'est DHCP (dns, sip, domain, ntp, etc et future truc car c'est extensible). Apres tout, DNS c'est une application sur IP tout comme HTTP ou autre. je vois pas pourquoi sa configuration serait faites a bas niveau dans le kernel (RA/RD) dans la couche 3. En plus en terme de ressource et d'admin le stateless dhcp est très simple, beaucoup plus que le v4 puisqu'on a pas de baux a gérer. ca n'a donc rien de débile, loin de la.

Bah justement, sur un gros réseau, il vaut mieux des RA ICMPv6 multicast qu'un milliers de transaction DHCPv6.

sur un gros réseau c'est plutot le contraire on prefere DHCPv6 car on a plus d'options , du partionnement, du relai, de la sécurité et de la gestion centralisée.

RDNSS a été surtout concu pour les tres petits réseaux (plus petit qu'un LAN freebox) et pour les réseaux mobiles (ou le changement de sous-réseau doit être rapide).

Au passage, la gestion RDNSS n'est pas faite dans le kernel linux mais remonte via netlink vers l'userspace.
 

ce qui démontre bien que la config DNS n'a rien à faire dans le kernel.

Il ne la récupère pas.

Il la choisit (après avoir s'être renseigné sur l'adresse du réseau, etc.).

explication simple:

au demarrage, chaque machine s'autoconfigure avec une IP dit 'link-local' formée du prefix fe80::/64 et d'une adresse sur 64 bits formée avec l'adresse MAC de la carte réseau encodée en EUI64. c'est tres similaire a l'autoconfiguration en IPv4 avec 169.254.0.0/16.

Cette IP locale permet de communiquer de suite en IP avec les autres equipements présents sur le LAN. Elle ne sert qu'a ca et ne permet pas de sortir du LAN.

Ensuite pas un systeme de pseudo-broadcast (ipv6 n'ayant pas de broadcast mais que du multicast) et d'écoute a base de messages icmpV6 (les fameux RA (Router Advertisement) et RS(Router Solicitation)), la machine obtient du routeur (la freebox dans notre cas) le prefix réseau public a utiliser pour sortir ainsi que la passerelle par défaut (la freebox elle meme). Avec ces infos, la machine s'autoconfigure a nouveau une 2eme adresse IP formée du prefix public recu et d'une adresse sur 64 bits. Cette fois on évite d'utiliser l'addresse MAC car elle permettrait de repérer l’équipement par un tiers. On utilise donc une adresse générée aléatoirement qu'on combien avec le préfix fourni par la box et ca donne l'IP public pour cette machine.

en pratique c'est plus compliqué que ca (inscriptions au multicast, vérification unicité d'adresse, etc)  mais en gros c'est l'idée.

a noter donc qu'un hote IPv6 se retouve avec au moins 3 adresses v6:
l'@ loopback (::1)
l'@ link-local (fe80::<MAC encodé sur 64 bits>)
l'@ publique (<prefix fourni par Free>::<aléatoire unique au lan>).