Difference between revisions of "MOOC:Compagnon Act32-s7"
From Livre IPv6
(→Autoconfiguration sans état) |
(→La configuration automatique des paramètres réseau) |
||
Line 192: | Line 192: | ||
Le message annonce de routeurs est émis vers le groupe de tous les noeuds IPv6 du lien. Le drapeau <tt>A</tt> étant positionné, le préfixe annoncé peut alors servir à la construction de l'adresse unicast globale. La durée de validité de cette adresse n'est pas limitée. La machine se configurant aura donc l'adresse <tt>3ffe:302:12:3:a00:20ff:fe0a:aa6d</tt>. | Le message annonce de routeurs est émis vers le groupe de tous les noeuds IPv6 du lien. Le drapeau <tt>A</tt> étant positionné, le préfixe annoncé peut alors servir à la construction de l'adresse unicast globale. La durée de validité de cette adresse n'est pas limitée. La machine se configurant aura donc l'adresse <tt>3ffe:302:12:3:a00:20ff:fe0a:aa6d</tt>. | ||
+ | |||
+ | === Découverte de la liste de serveurs DNS récursifs === | ||
+ | |||
+ | L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 4862, 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'était 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. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document 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, RFC 5006, mécanisme à base d'annonce de routeur (RA): cette proposition apporte un complément à l'autoconfiguration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Une telle extension n'a pas été standardisée à ce jour, le RFC étant dans un état EXPERIMENTAL ; | ||
+ | * Proposition 3, mécanisme à base d'adresses anycast bien connues (''Well-known anycast addresses'') : des adresses IPv4 et IPv6 [[anycast]] 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. Cette proposition semble avoir été abandonnée. |
Revision as of 23:17, 29 March 2015
La configuration automatique des paramètres réseau
Mécanismes mis en oeuvre
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et fastidieux. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (plug and play) à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous avons vu comment les routes étaient installées dans la table de routage des machines. Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :
- l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
- l'obtention de la nouvelle adresse suite à la renumérotation des machines du site après un changement d'opérateur. L'opération de renumérotation revient concrètement à changer la partie haute de l'adresse. L'autoconfiguration d'adresses va servir de vecteur dans l'attribution du nouveau préfixe.
Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, la vérification de son unicité et la détermination d'adresses unicast globales. IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :
- l'autoconfiguration sans état (stateless autoconfiguration, RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrits dans la suite de ce chapitre.
- l'autoconfiguration avec état (stateful autoconfiguration) ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses (cf. DHCPv6).
Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. Annonce du routeur) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit M (Managed address configuration) mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit O (Other stateful configuration) indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :
- La toute première étape consiste à créer l'adresse lien-local.
- Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
- La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
- S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
- l'autoconfiguration sans état,
- l'autoconfiguration avec état.
- En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.
Création de l'adresse lien-local
À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (FE80::/64) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.
Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.
Détection d'adresse dupliquée
Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 sollicitation d'un voisin et annonce d'un voisin. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :
- Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
- Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
- Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.
A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.
Autoconfiguration sans état
L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.
Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.
La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
Configuration de la route par défaut
En IPv6 seuls les routeurs utilisent des protocoles de routage pour définir leurs tables de routage. Le routage des autres machines repose sur la notion de route par défaut. Comme avec IPv4, l'envoi de messages de redirection est utilisé pour installer de meilleures routes. Périodiquement les routeurs envoient des Annonces du routeur qui permettent aux machines sur le câble de choisir un routeur par défaut, et aussi de calculer leur adresse (dans le mode d'autoconfiguration sans état stateless).
Un même câble Ethernet relie 3 machines (cf. figure Annonces de routeurs) :
- deux routeurs ganesha et tuna,
- et une autre machine uma.
Les routeurs émettent périodiquement sur le réseau des messages d'annonce.
Ethernet Src : 1a:0:20:c:7a:34 Dst : 33:33:0:0:0:1 Type : 0x86dd IPv6 Version : 6 Classe : 0xf Label : 000000 Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0xff) Source : fe80::1800:200c:7a34 (ganesha, lien-local) Desti. : ff02::1 (multicast, tous les noeuds du lien) ICMPv6 Type : 134 (0x86, Annonce de routeur) Code : 0 Checksum : 0x773c Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP) Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés) Options : Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34 Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04) Drapeaux : L=1, A=1 Durée de validité : -1, -1 (infinie) Préfixe : 3ffe:302:12:3::/64
0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34| 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 0050: 3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 00
Ce message est envoyé par le routeur ganesha (l'adresse source est l'adresse locale, commençant par fe80), à destination de tous les noeuds sur le câble Ethernet (adresse de destination IPv6 «Tous les noeuds sur le lien» ff02::1 et l'adresse de destination physique est l'adresse MAC de multicast associée). Les informations donnent la durée de vie de cette annonce, des paramètres de configuration pour les noeuds, dont le type de construction d'adresse : mode d'autoconfiguration stateless en créant une adresse permanente à partir du préfixe 3ffe:302:12:3::/64.
La table de routage d'uma après réception de ce message contient :
uma# netstat -nrf inet6 Routing tables IPv6: Destination Gateway Flags Refs Use Mtu Interf default fe80::1800:20ff:fe0c:7a34 UGS 0 17 1500 le0 fe80::1800:20ff:fe0c:7a34 1a:0:20:c:7a:34 U HDL 1 2 1500 le0 .....
La ligne avec le drapeau L correspond à une machine directement accessible, le champ Gateway contient l'adresse IEEE 802. Il s'agit des informations contenues dans la table de correspondance construite par le protocole de découverte des voisins.
Le routeur tuna avait lui aussi émis des annonces de routeur. On pourrait donc aussi enregistrer une route par défaut via tuna ; mais le système ne conserve qu'une route par défaut, et la route possible par tuna est ignorée. De même, il n'y a pas de ligne de correspondance adresse IPv6-adresse Ethernet pour tuna car cette adresse n'a pas été utilisée comme destination.
Exemple de configuration automatique
La machine à l'activation de l'interface réseau crée l'adresse lien-local provisoire et débute l'algorithme DAD. Elle émet un message de sollicitation d'un voisin à l'adresse multicast sollicité associée à son adresse provisoire. Son adresse de source est indéterminée car son état est encore provisoire pour le moment et ne sert que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ cible.
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd IPv6 Version : 6 Priorité : 0xf0 Label: 000000 Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0x0ff) Source : :: Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible) ICMPv6 Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37 cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local) 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00 0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d
Ce message ne peut être utilisé pour mettre à jour le cache de résolution d'adresses d'un voisin car l'adresse de la source a un statut de provisoire, en conséquence l'option adresse physique de la source ne figure pas dans le message. Le message de sollicitation d'un voisin sera émis au moins deux fois. Si rien n'est reçu, l'identifiant sera considéré unique et l'adresse passera dans l'état valide. Par contre, si elle reçoit le message annonce d'un voisin comme ci-dessous, l'adresse est entrée en collision avec une adresse valide utilisée par un voisin. L'adresse ne peut être affectée à l'interface. Une intervention humaine devient nécessaire.
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:0:0:0:1 Type : 0x86dd IPv6 Version : 6 Priorité : 0xf0 Label: 000000 Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0x0ff) Source : fe80::a00:20ff:fe0a:aa6d Desti. : ff02::1 (multicast, tous les noeuds du lien) ICMPv6 Type : 136 (0x88, Annonce d'un voisin) Code : 0 Checksum : 0xe036 Bits (0x7) R = 0, S = 0, O = 1 cible : fe80::a00:20ff:fe0a:aa6d Option : Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d 0000: 6f 00 00 00 00 20 3a ff fe 80 00 00 00 00 00 00 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 01|88 00 e0 36 20 00 00 00 0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d| 0040: 02 01 08 00 20 0a aa 6d
Comme le message sollicitation d'un voisin ne comportait pas d'adresse de source, le message annonce d'un voisin est émis au groupe de tous les noeuds du lien (ff02::1).
Après avoir exécuté l'algorithme DAD avec l'adresse lien-local comme l'exemple précédent l'a montré (en supposant que l'adresse n'est pas entrée en collision), la machine émet un message sollicitation du routeur à tous les routeurs du lien (ff02::2).
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:0:0:0:2 Type : 0x86dd IPv6 Version : 6 Priorité : 0xf0 Label: 000000 Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0x0ff) Source : fe80::a00:20ff:fe0a:aa6d (uma, lien-local) Desti. : ff02::2 (multicast, tous les routeurs du lien) ICMPv6 Type : 133 (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e Option : Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d 0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00| 0030: 01 01 08 00 20 0a aa 6d
Si un routeur est présent, un message annonce de routeur est reçu par la machine se configurant. Elle y trouve les bits M, O et les informations sur les préfixes du lien.
Ethernet Src : 1a:0:20:c:7a:34 Dst : 33:33:0:0:0:1 Type : 0x86dd IPv6 Version : 6 Priorité : 0xf0 Label: 000000 Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0x0ff) Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local) Desti. : ff02::1 (multicast, tous les noeuds du lien) ICMPv6 Type : 134 (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP) Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés) Options : Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34 Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04) Drapeaux : L=1, A=1 Durée de validité : -1, -1 (infinie) Préfixe : 3ffe:302:12:3::/64 0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34| 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 0050: 3f fe 03 02 00 12 00 03 00 00 00 00 00 00 00 00
Le message annonce de routeurs est émis vers le groupe de tous les noeuds IPv6 du lien. Le drapeau A étant positionné, le préfixe annoncé peut alors servir à la construction de l'adresse unicast globale. La durée de validité de cette adresse n'est pas limitée. La machine se configurant aura donc l'adresse 3ffe:302:12:3:a00:20ff:fe0a:aa6d.
Découverte de la liste de serveurs DNS récursifs
L'autoconfiguration IPv6 sans état, telle que spécifiée dans le RFC 4862, 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'était 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. Les co-auteurs de ces trois propositions ont conjointement rédigé un document synthétique (RFC 4339) décrivant pour chaque technique le fonctionnement ainsi que les scénarios d'utilisation. Ce document 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, RFC 5006, mécanisme à base d'annonce de routeur (RA): cette proposition apporte un complément à l'autoconfiguration sans état (RFC 4862) et consiste à surcharger l'annonce du routeur, en tant que message de la découverte des voisins (RFC 4861) par l'information DNS nécessaire. Une telle extension n'a pas été standardisée à ce jour, le RFC étant dans un état EXPERIMENTAL ;
- Proposition 3, mécanisme à base d'adresses anycast bien connues (Well-known anycast addresses) : des adresses IPv4 et IPv6 anycast 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. Cette proposition semble avoir été abandonnée.