MOOC:Compagnon Act32-s7

From Livre IPv6

Revision as of 11:06, 9 April 2016 by Vlerouvillois (Talk | contribs) (La découverte de la liste de serveurs DNS)


Activité 32: Configurer automatiquement les paramètres réseau

Principe de l'auto-configuration

La précédente activité a présenté le mécanisme de découverte des voisins afin qu'une station connectée à un lien puisse récupérer automatiquement les adresses des autres stations du même lien. C'est la même philosophie qui est mise en oeuvre dans la configuration automatique des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour :

  • que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;
  • que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.

Les informations nécessaires à la configuration d'une interface réseau se composent, au minimum :

  • des informations pour déterminer l'adresse IP, ou des informations indiquant la méthode pour l'obtenir,
  • de la longueur du préfixe IP du réseau,
  • de l'adresse du routeur local à utiliser pour la route par défaut (la route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local),
  • du serveur de noms à utiliser.

L'administrateur renseigne les informations communes pour un lien sur un équipement. Les stations récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface. La connexion au réseau sera alors effective pour l'utilisateur. Ce mécanisme est donc prévu pour les hôtes. Les équipements intermédiaires dans l'infrastructure, comme les routeurs, ne sont pas censés utiliser ce mécanisme, et leur configuration est à la charge de l'administrateur.

Mécanismes mis en oeuvre

L'auto-configuration se déroule en plusieurs étapes mettant en oeuvre différents mécanismes :

  • La toute première étape consiste à créer l'adresse "lien-local". Une fois l'unicité de cette adresse vérifiée, le nouveau noeud est en mesure de communiquer avec les autres noeuds du lien.
  • Le nouveau noeud doit ensuite acquérir les informations propres au réseau communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. 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'auto-configuration sans état,
    • ou l'auto-configuration avec état.
  • Les informations transmises par le routeur permettent de plus, au noeud, de configurer sa table de routage.
  • Enfin, toujours en fonction de la politique de configuration, le noeud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.

En l'absence de routeur sur le lien, le noeud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse "lien-local". Le noeud n'a pas une adresse avec une portée qui l'autorise à communiquer avec des noeuds autres que ceux de son lien d'attachement.

La création de l'adresse "lien-local"

À l'initialisation de son interface, le nouveau noeud du lien construit un identifiant pour l'interface qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse "lien-local" est donc créée en prenant le préfixe "lien-local" (FE80::/64) standardisé pour cet usage.

L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car le noeud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée, présentée dans l'activité précédente. Si le noeud détermine que l'adresse "lien-local" n'est pas unique, l'auto-configuration 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'auto-configuration est achevée.

La fourniture des paramètres communs au réseau

La seconde étape de l'auto-configuration consiste, pour le noeud qui se configure, à récupérer les informations communes à son lien d'attachement. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Les routeurs sont sous la responsabilité directe de l'administrateur qui aura en charge de les configurer. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité.

Figure 1 : Format du message de sollicitation d'un routeur

La transmission de ces informations est assurée par un échange de messages ICMPv6 :

  • Un message de sollicitation d'un routeur, noté RS (Router Solicitation) (cf. figure 1). Ce message ICMPv6 est identifié par le champ type de valeur 133.
  • Un message d'annonce de routeur, noté RA (Router Advertisement) (cf. figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ type de valeur 134.

La sollicitation d'un routeur est un message de requête émis par le noeud qui se configure afin de découvrir le ou les routeurs du lien, et pour obtenir des informations pour une configuration offrant une connectivité pour des communications "inter-liens". Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien ff02::2. Le champ option contient normalement l'adresse physique du noeud demandeur.

Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un noeud. Le champ adresse source dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le noeud qui a émis la sollicitation, soit le groupe multicast de tous les noeuds du lien identifié par l'adresse ff02::01. Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des noeuds la présence du ou des routeurs afin de confirmer la connectivité "inter-lien". Ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés avec de mauvaises informations comme le note le RFC 6104. Ces messages sont même qualifiés de RAcailles[1].

Figure 2 : Format du message d'annonce de routeur

Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :

  • durée de vie du routeur ; il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut.
  • durée d'accessibilité ; ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un noeud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information.
  • temporisation de retransmission ; ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres noeuds à détecter une inaccessibilité du routeur.

La politique de configuration, qui doit indiquer au noeud qui se configure les mécanismes à utiliser, est définie par 2 bits du message d'annonce de routeur :

  • Le bit M (Managed address configuration) mis à 1, indique que le noeud ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes éventuellement reçus en option du même message. Il doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration avec état de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration sans état [RFC 4862] doit être utilisé.
  • Le bit O (Other stateful configuration) mis à 1, indique que le noeud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse.

L'auto-configuration sans état pour une adresse IP non limitée au lien

Le principe de base de l'auto-configuration sans état de l'adresse IP est qu'un noeud génère son adresse IPv6 à partir d'informations locales et d'informations fournies par le routeur. Le routeur communique au noeud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.

Figure 3 : Format de l'option d'information sur le préfixe

L'option information sur le préfixe est composée par les champs suivants:

  • type, de valeur 3, identifie cette option.
  • longueur indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4.
  • lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé.
  • Le bit L (On link) signifie, quand il est à 1, que le préfixe indique que les autres noeuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le noeud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection.
  • Le bit A (Autonomous address-configuration) indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du noeud.
  • durée de validité indique, en secondes, la durée pendant laquelle le préfixe est valide.
  • durée préférable indique la durée, en secondes, pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable». Pour ce champ et celui de durée de validité, une valeur de 0xffffffff représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
  • réservé est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits.
  • préfixe contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.

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 ici du message d'annonce de routeurs, et plus précisément de l'option «information sur le préfixe». Pour construire son adresse, le noeud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 4941]. Profitant de la souplesse offerte par IPv6, le noeud peut de plus créer autant d'adresses qu'il souhaite.

Les valeurs de durée préférable et de durée de validité contrôlent le cycle de vie des adresses créées. Une fois le temps indiqué par durée préférable écoulé, l'adresse créée à partir du préfixe concerné passera de l'état préféré à l'état déprécié. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur. Et, lorsque le temps indiqué par la durée de validité sera écoulé, l'adresse passera de son état à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les noeuds d'adresses construites à partir de certains préfixes.

L'auto-configuration avec état de l'adresse IP

Cette méthode de configuration d'adresse repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le noeud va solliciter le serveur en utilisant le protocole DHCPv6, présenté dans l'activité suivante.

Une station recevant un message d'annonce de routeur est donc supposée initier un dialogue avec un serveur DHCPv6 si ce message présente le bit M avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en oeuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 à la station, alors que cette information est fournie par le réseau.

La configuration de la table de routage

En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres noeuds repose sur la notion de route directe (ou locale) et de route par défaut.

Route par défaut

La route par défaut représente l'ensemble des routes de l'Internet. Cela correspond au panneau "Toutes Directions" sur un réseau routier. Dans un réseau de distribution qui connecte des utilisateurs, la route par défaut dirige le trafic vers le routeur qui a la connectivité Internet.

La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le noeud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le noeud destinataire est localisé sur le même lien. Le noeud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.

La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse "lien-local" contenue dans le champ source du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un noeud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.

La découverte de la liste des serveurs DNS

L'auto-configuration 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. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration avec état. Les spécifications du protocole d'auto-configuration avec état par DHCPv6, ont pris du temps (six ans environ) pour être publiées dans le RFC 3315. Pendant ce temps, le besoin de découverte des serveurs DNS s'est fait plus pressant. Pour soutenir l'effort de déploiement d'IPv6, la communauté IPv6 s'est retrouvée à mettre en oeuvre un mécanisme de découverte automatique du DNS.

À l'IETF, trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes de IPv6, DHC (Dynamic Host Configuration) et DNSOP (Domain Name System Operations). C'est le groupe DNSOP qui a pris en charge les débats sur ces propositions. Les coauteurs 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.

La première proposition repose sur le protocole DHCP. Dans ce contexte, 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 pour la découverte du DNS :

  • par un serveur DHCPv6 complet [RFC 3315] ; le serveur alloue également les adresses IPv6 ;
  • par un serveur DHCPv6-lite [RFC 3736] qui n'alloue pas d'adresses IPv6 mais est simplement chargé d'informer les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...

Dans les deux cas, si le noeud 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 obtenues quand celles-ci sont incohérentes.

La seconde proposition a été développée sur la base des messages ICMPv6 RA. Cette proposition, spécifiée dans le RFC 6106 et appelée ND RDNSS (Neighbor Discovery Recursive DNS Server), apporte un complément à l'auto-configuration sans état [RFC 4862]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS.

La troisième proposition s'appuie sur des adresses anycast bien connues (Well-known anycast addresses). Les adresses IPv4 et IPv6 anycast seraient connues par tous les clients et pré-configurées automatiquement par le logiciel d'installation du système d'exploitation du noeud. Cette proposition semble avoir été abandonnée et n'a pas été reprise dans un autre document de spécifications.

La disponibilité des mécanismes DHCPv6 et ND RDNSS au sein d'un système d'exploitation varie en fonction des systèmes[2].

Exemple de configuration automatique

Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le noeud et le routeur du lien comme montré par la figure 4.

Figure 4: Configuration de l'exemple.

Préalablement à l'attachement du noeud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. Le noeud, à l'activation de son interface réseau, crée une adresse lien-local provisoire à partir de l'adresse matérielle de celle-ci. Afin de vérifier si cette adresse est unique, la station débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 5).

Création d'un identifiant d'interface

La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité utilisation des adresses sur une interface réseau de la séquence 1. En résumé, cela consiste à inverser la valeur du 7ieme bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3ième octet la valeur OxFFFE.

Figure 5: Procédure DAD.

Comme décrit dans l'activité précédente, 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. La capture ci-dessous montre le message ICMPv6 NS émis.

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 (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

Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire. Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse lien-local comme unique. L'adresse perd son état provisoire et devient valide.

Cette première étape terminée, la station possède donc une adresse lien-local pour communiquer avec les noeuds présents sur le même lien. Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des noeuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : ff02::2 comme indiqué par la figure 6.

Figure 6: Demande du préfixe IPv6 pour une adresse IPv6 non local.

Le message ainsi émis est présenté ci-dessous sous sa forme capturée:

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 (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 ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits M, O ainsi que les informations sur le ou les préfixes du lien. La figure 7 montre la réception du message d'annonce du routeur.

Figure 7: Réception d'un message RA.

Le message annonce de routeur 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 d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse 2001:db8:12:3:a00:20ff:fe0a:aa6d à partir du préfixe et de l'identifiant d'interface.

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 : 2001:db8: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: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00


De la même façon que l'unicité de l'adresse lien-local a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse unicast globale construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 8.

Figure 8: Détection d'adresse dupliquée.

Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse lien-local du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à la l'issue de la phase d'auto-configuration est indiqué par la figure 9. La station est désormais capable de communiquer avec des noeuds situés au delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser peuvent être communiquées dans le message d'annonce de routeur.

Figure 9: Les adresses allouées.

Conclusion

La configuration automatique des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et facilite donc grandement la vie des administrateurs réseau. La configuration est centralisée sur le routeur du réseau qui devient l'équipement crucial à son bon fonctionnement. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.

Cependant la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.

Références bibliographiques

  1. Bortzmeyer, S. (2013). Article. Rogue IPv6 Router Advertisement Problem Statement
  2. Wikipedia. Comparison of IPv6 support in operating systems


Pour aller plus loin

  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
  • RFC 4291 IP Version 6 Addressing Architecture
  • RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches
  • RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
  • RFC 4862 IPv6 Stateless Address Autoconfiguration
  • RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
  • RFC 6104 Rogue IPv6 Router Advertisement Problem Statement
  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration
Personal tools