Difference between revisions of "MOOC:Compagnon Act32-s7"

From Livre IPv6

(→‎Découverte des paramètres communs au réseau)
(→‎La découverte des préfixes de traduction)
 
(66 intermediate revisions by 4 users not shown)
Line 4: Line 4:
 
-->
 
-->
 
__NOTOC__
 
__NOTOC__
−
= Activité 32: Configurer automatiquement les paramètres réseau =
+
= Activité 32: Configurer automatiquement les paramètres de connectivité =
−
 
+
<!-- = Activité 32: Configurer automatiquement les paramètres réseau = -->
 
== Principe de l'auto-configuration ==
 
== 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 (ou auto-configuration) 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 :  
+
La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) 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'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.
 
* 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.
 
{{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut  correspond au panneau "Toutes Directions".}}
 
{{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut  correspond au panneau "Toutes Directions".}}
 
L'auto-configuration vise à fournir les informations  pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants :  
 
L'auto-configuration vise à fournir les informations  pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants :  
−
* les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir,
+
* les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;
−
* la longueur du préfixe IP du réseau,
+
* la longueur du préfixe IP du réseau ;
−
* l'adresse du routeur local à utiliser pour la route par défaut,
+
* l'adresse du routeur local à utiliser pour la route par défaut ;
 
* le serveur de noms à utiliser.
 
* le 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 réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet sera alors effective. La station sera alors en mesure de recevoir et d'émettre des paquets IP.   
+
L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP.   
 
   
 
   
−
L'auto-configuration est un mécanisme 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.
+
L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements "gérés", ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.
  
−
== Mécanismes mis en oeuvre ==
+
== Mécanismes mis en œuvre ==
−
{{HorsTexte|Avec ou sans état|Le terme 'sans état' signifie une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours ou attendre des informations (ou état) d'un serveur comme c'est le cas avec DHCP. }}
+
{{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}
−
L'auto-configuration se déroule en plusieurs étapes mettant en oeuvre différents mécanismes :  
+
L'auto-configuration se déroule en plusieurs étapes mettant en œuvre 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.
+
* la toute première étape consiste à créer l'adresse "lien-local". Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;
−
* Le nouveau noeud doit ensuite acquérir les informations 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 :
+
* le nouveau nœud doit ensuite acquérir les informations 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" (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],
 
** l'auto-configuration "sans état" (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],
−
** ou l'auto-configuration "avec état" [RFC 3315].
+
** ou l'auto-configuration "avec état" (par DHCPv6) [RFC 8415] ;
−
* Les informations transmises par le routeur permettent de plus, au noeud, de configurer sa table de routage.
+
* les informations transmises par le routeur permettent de plus, au nœud, 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.
+
* enfin, toujours en fonction de la politique de configuration, le nœud 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.
+
En l'absence de routeur sur le lien, le nœud 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 nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.
  
 
=== La création de l'adresse "lien-local" ===
 
=== La création de l'adresse "lien-local" ===
−
À l'initialisation de son interface, le nouveau noeud 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" (<tt>FE80::/64</tt>) standardisé pour cet usage.  
+
À l'initialisation de son interface, le nouveau nœud 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" (<tt>fe80::/64</tt>) standardisé pour cet usage.  
  
−
L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') 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.
+
L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud 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. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.
 
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. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.
Line 41: Line 41:
 
=== Découverte des paramètres communs au réseau ===
 
=== Découverte des paramètres communs au réseau ===
  
−
L'objectif du noeud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications "inter-liens". La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.
+
L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications "inter-liens". La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.
  
−
Dans cette étape de l'auto-configuration, l'hôte vise à obtenir, du routeur local, les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages émis périodiquement par le routeur, soit en envoyant une requête au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :
+
Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :
−
* Sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ <tt>type</tt> de valeur 133.
+
* sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ <tt>type</tt> de valeur 133 ;
−
* Annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ <tt>type</tt> de valeur 134.
+
* annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ <tt>type</tt> de valeur 134.
 
<center>
 
<center>
 
[[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]
 
[[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]
 
</center>
 
</center>
−
La sollicitation d'un routeur forme une requête émise par le noeud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Le champ <tt>option</tt> contient normalement l'adresse physique du noeud demandeur.
+
La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Le champ <tt>option</tt> contient normalement l'adresse physique du nœud 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 <tt>adresse source</tt> 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 <tt>ff02::1</tt>.
+
Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ <tt>adresse source</tt> dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse <tt>ff02::1</tt>.
−
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<ref>Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]</ref>.
+
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 nœuds la présence du ou des routeurs afin de confirmer la connectivité "inter-lien".  
 +
 
 +
'''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles<ref>Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]</ref>.''
  
 
<center>
 
<center>
Line 59: Line 61:
  
 
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 :
 
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 :
−
*  <tt>durée de vie du routeur</tt> ; il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut.
+
*  <tt>durée de vie du routeur</tt> : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;
−
* <tt>durée d'accessibilité</tt> ; 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.
+
* <tt>durée d'accessibilité</tt> : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud 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 ;
−
* <tt>temporisation de retransmission</tt> ; 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.
+
* <tt>temporisation de retransmission</tt> : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.
  
−
Communiquée au noeud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par 2 bits du message d'annonce de routeur :
+
Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :
−
* Le bit <tt>M</tt> (''Managed address configuration'') mis à 1, indique que le noeud  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" doit être utilisé pour construire une adresse IPv6.
+
* le bit <tt>M</tt> (''Managed address configuration'') mis à 1, indique que le nœud 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" doit être utilisé pour construire une adresse IPv6 ;
−
* Le bit <tt>O</tt> (''Other stateful configuration'') mis à 1, indique que le noeud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont  inclus dans le message d'annonce de routeur au moyen d'options spécifiques.
+
* le bit <tt>O</tt> (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont  inclus dans le message d'annonce de routeur au moyen d'options spécifiques.
  
 
=== L'auto-configuration "sans état" pour une adresse IP routable ===
 
=== L'auto-configuration "sans état" pour une adresse IP routable ===
  
−
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 (son identifiant d'interface) et de préfixes éventuellement reçus du 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.
+
Le principe de base de l'auto-configuration "sans état" de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.
  
 
<center>
 
<center>
Line 75: Line 77:
 
</center>
 
</center>
  
−
L'option information sur le préfixe est composée par les champs suivants:
+
L'option information sur le préfixe est composée par les champs suivants :
−
* <tt>type</tt>, de valeur 3, identifie cette option.
+
* <tt>type</tt>, de valeur 3, identifie cette option ;
−
* <tt>longueur</tt> indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4.
+
* <tt>longueur</tt> indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ;
−
* <tt>lg.préfixe</tt> indique combien de bits sont significatifs pour le préfixe annoncé.
+
* <tt>lg.préfixe</tt> indique combien de bits sont significatifs pour le préfixe annoncé ;
−
* Le bit <tt>L</tt> (''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 <tt>L</tt> (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud é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 <tt>A</tt> (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du noeud.
+
* le bit <tt>A</tt> (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;
−
* <tt>durée de validité</tt> indique, en secondes, la durée pendant laquelle le préfixe est valide.
+
* <tt>durée de validité</tt> indique, en secondes, la durée pendant laquelle le préfixe est valide ;
−
* <tt>durée préférable</tt> indique la durée de préférence, en secondes pour une adresse construite avec l'auto-configuration "sans état". Pour ce champ et celui de <tt>durée de validité</tt>, une valeur de <tt>0xffff ffff</tt> représente une durée infinie.
+
* <tt>durée préférable</tt> indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration "sans état". Pour ce champ et celui de <tt>durée de validité</tt>, une valeur de <tt>0xffff ffff</tt> représente une durée infinie ;
−
* <tt>réservé</tt> est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits.
+
* <tt>réservé</tt> est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;
 
* <tt>préfixe</tt> 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.
 
* <tt>préfixe</tt> 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 IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L"adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du noeud. Une adresse routable est soit une adresse de type ULA ou soit une adresse tirée du plan d'adressage global.  
+
{{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement "off-link") a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.
−
Le préfixe de l'adresse routable 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.
+
 
 +
Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état "off-link" d'une adresse est alors significatif.
 +
 
 +
Au passage, la précaution de forcer le champ "Hop-limit" à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.
 +
 
 +
L'introduction, dans les infrastructures de type "cloud" de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}
 +
Comme pour la création de l'adresse "lien-local", l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L"adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA).  
 +
Le préfixe de l'adresse routable 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 nœud 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 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.
  
 
Les valeurs de <tt>durée préférable</tt> et de <tt>durée de validité</tt> contrôlent le cycle de vie des adresses créées. Une fois la <tt>durée préférable</tt> écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.
 
Les valeurs de <tt>durée préférable</tt> et de <tt>durée de validité</tt> contrôlent le cycle de vie des adresses créées. Une fois la <tt>durée préférable</tt> écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. 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  à 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. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
+
Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera  à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.
  
  
Line 99: Line 108:
 
=== L'auto-configuration "avec état" de l'adresse IP routable ===
 
=== L'auto-configuration "avec état" de l'adresse IP routable ===
  
−
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.
+
Cette méthode de configuration d'adresse <!-- , qui sera présentée dans l'activité suivante,--> repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.
  
−
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 <tt>M</tt> 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.
+
Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit <tt>M</tt> 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 œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.
 +
 
 +
Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode "non connecté", sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.
  
 
=== La configuration de la table de routage ===
 
=== 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.  
+
En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut.  
  
−
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 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 nœud 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 nœud destinataire est localisé sur le même lien. Le nœud é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 <tt>source</tt> 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.<br>
+
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 <tt>source</tt> 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 nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.
−
Cependant lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route [RFC 4191]. Ce message va pouvoir indiquer la ou les routes désservies par le routeur.
+
 
 +
Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.
  
 
=== La découverte des serveurs DNS ===
 
=== La découverte 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 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. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les coauteurs des 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.<br>
+
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 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 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des 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.<br>
 
Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.
 
Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.
  
−
La première proposition mise en oeuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646.  Un serveur DHCPv6 dit "sans état" [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...
+
La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646.  Un serveur DHCPv6 dit "sans état" [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...
−
Depuis, le protocole DHCPv6 pour serveur "avec état" a été développé [RFC 3315]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.
+
Depuis, le protocole DHCPv6 pour serveur "avec état" a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.
 +
 
 +
La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS.
 +
 
 +
La disponibilité des mécanismes DHCPv6 et ND RDNSS  dépend des systèmes d'exploitation<ref>APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]</ref>.
 +
 
 +
=== La découverte des préfixes de traduction ===
 +
Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes  NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DNS64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).
  
−
La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 6106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS.  
+
En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes :
 +
* déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;
 +
* déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements).  
 +
'''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''
  
−
La disponibilité des mécanismes DHCPv6 et ND RDNSS  dépend des systèmes d'exploitation<ref>Wikipedia. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]</ref>.
+
<!--
 +
{{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}
 +
-->
  
 
== Exemple de configuration automatique ==
 
== 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 5.
+
Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.
  
 
<center>
 
<center>
Line 131: Line 155:
 
</center>
 
</center>
  
−
Préalablement à l'attachement du noeud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien.  
+
Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien.  
−
Le noeud, à l'activation de son interface de communication au réseau, crée une adresse "lien-local" provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le noeud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).
+
Le nœud, à l'activation de son interface de communication au réseau, crée une adresse "lien-local" provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).
−
{{HorsTexte|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 7<sup>e</sup> bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3<sup>e</sup> octet, la valeur <tt>OxFFFE</tt>.}}
+
{{HorsTexte|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 7<sup>e</sup> bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3<sup>e</sup> octet, la valeur <tt>OxFFFE</tt>.}}
  
 
<center>
 
<center>
Line 140: Line 164:
  
 
Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse "multicast sollicitée" associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ <tt>cible</tt>. La capture ci-dessous montre le message ICMPv6 NS émis.
 
Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse "multicast sollicitée" associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ <tt>cible</tt>. 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
+
  <font color="green">Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd</font>
 
  IPv6
 
  IPv6
−
   Version : 6 Priorité : 0xf0 Label: 000000
+
   Version : 6 Priorité : 0x00 Label: 000000
 
   Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)
 
   Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)
 
   Nombre de sauts : 255 (0x0ff)
 
   Nombre de sauts : 255 (0x0ff)
 
   Source : ::
 
   Source : ::
 
   Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)
 
   Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)
−
  ICMPv6
+
  <font color="blue">ICMPv6
 
   Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37
 
   Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37
−
   cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)
+
   cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)</font>
 
   
 
   
−
  0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00
+
  0000: <font color="green">33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd</font>|60 00
−
  0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00
+
0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00
−
  0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00
+
  0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00
−
  0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d
+
  0030: 00 01 ff 0a aa 6d|<font color="blue">87 00 fe 37 00 00 00 00 fe 80</font>
 +
  0040: <font color="blue">00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d</font>
 +
 
  
 
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 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.
 
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 : <tt>ff02::2</tt> comme indiqué par la figure 7.
+
Cette première étape terminée, la station possède donc une adresse "lien-local" pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds 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 : <tt>ff02::2</tt> comme indiqué par la figure 7.
 
<center>
 
<center>
 
[[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]
 
[[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]
 
</center>
 
</center>
−
Le message ainsi émis est présenté ci-dessous sous sa forme capturée:
+
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
+
  <font color="green">Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd</font>
 
  IPv6
 
  IPv6
−
   Version : 6 Priorité : 0xf0 Label: 000000
+
   Version : 6 Priorité : 0x00 Label: 000000
 
   Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)
 
   Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)
 
   Nombre de sauts : 255 (0x0ff)
 
   Nombre de sauts : 255 (0x0ff)
 
   Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)
 
   Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)
 
   Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)
 
   Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)
−
  ICMPv6
+
  <font color="blue">ICMPv6
 
   Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e
 
   Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e
 
   Option :
 
   Option :
−
   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d
+
   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d</font>
 
   
 
   
−
  0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00
+
  0000: <font color="green">33 33 00 00 00 02 08 00 20 0a aa 6d 86 dd</font>|60 00
−
  0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00
+
0010: 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0a 00
−
  0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|
+
  0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00
−
  0030: 01 01 08 00 20 0a aa 6d
+
  0030: 00 00 00 00 00 02|<font color="blue">85 00 d6 3e 00 00 00 00 01 01</font>
 +
  0040: <font color="blue">08 00 20 0a aa 6d</font>
  
 
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 <tt>M</tt> et <tt>O</tt>, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.
 
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 <tt>M</tt> et <tt>O</tt>, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.
Line 187: Line 214:
 
</center>
 
</center>
  
−
Le message "annonce de routeur" 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 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 <tt>2001:db8:12:3:a00:20ff:fe0a:aa6d</tt> à partir du préfixe et de l'identifiant d'interface.
+
Le message "Annonce de routeur" est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau <tt>A</tt> é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 <tt>2001:db8:12:3:a00:20ff:fe0a:aa6d</tt> à 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
+
  <font color="green">Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd</font>
 
  IPv6
 
  IPv6
−
   Version : 6 Priorité : 0xf0 Label: 000000
+
   Version : 6 Priorité : 0x00 Label: 000000
 
   Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)
 
   Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)
 
   Nombre de sauts : 255 (0x0ff)
 
   Nombre de sauts : 255 (0x0ff)
 
   Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)
 
   Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)
−
   Desti. : '''ff02::1''' (multicast, tous les noeuds du lien)
+
   Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)
−
  ICMPv6
+
  <font color="blue">ICMPv6
−
   Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c
+
   Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x8c83
 
   Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)
 
   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)
 
   Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)
Line 203: Line 230:
 
   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
 
   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)
 
   Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)
−
  Drapeaux : L=1, '''A=1'''  
+
    Longueur Préfixe : '''64''' (0x40)
−
  Durée de validité : -1 (infinie)
+
    Drapeaux : L=1, '''A=1''' (0xc)
−
  Durée préférable  : -1 (infinie)
+
    Durée de validité : -1 (infinie)
−
  Préfixe : '''2001:db8:12:3::/64'''
+
    Durée préférable  : -1 (infinie)
 +
    Préfixe : '''2001:db8:12:3::'''</font>
 
    
 
    
−
  0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00
+
  0000: <font color="green">33 33 00 00 00 01 1a 00 20 0c 7a 34 86 dd</font>|60 00
−
  0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00
+
0010: 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 18 00
−
  0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70
+
  0020: 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 00 00
−
  0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|
+
  0030: 00 00 00 00 00 01|<font color="blue">86 00 8c 83 00 00 17 70 00 00</font>
−
  0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00
+
  0040: <font color="blue">00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|03 04</font>
−
  0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00
+
  0050: <font color="blue">40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 20 01</font>
 +
  0060: <font color="blue">0d b8 00 12 00 03 00 00 00 00 00 00 00 00</font>
  
  
Line 222: Line 251:
 
</center>
 
</center>
  
−
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 à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. 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.
+
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 à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds 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.
  
 
<center>
 
<center>
 
[[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]
 
[[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]
 
</center>
 
</center>
 +
 +
<!--
 +
{{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}
 +
-->
  
 
== Conclusion ==
 
== Conclusion ==
Line 232: Line 265:
 
L'auto-configuration "sans état" des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.
 
L'auto-configuration "sans état" des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.
  
−
L'auto-configuration "sans état" a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur. En particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement à l'attachement des informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses noeuds peut être facilité par la configuration automatique.
+
L'auto-configuration "sans état" a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.
  
 
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.
 
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.
Line 243: Line 276:
 
RFC et leur analyse par S. Bortzmeyer :
 
RFC et leur analyse par S. Bortzmeyer :
  
−
* RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
 
 
* RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]
 
* RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]
 
* RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6  
 
* RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6  
Line 251: Line 283:
 
* RFC 4861 Neighbor Discovery for IP version 6 (IPv6)  [http://www.bortzmeyer.org/4861.html Analyse]
 
* RFC 4861 Neighbor Discovery for IP version 6 (IPv6)  [http://www.bortzmeyer.org/4861.html Analyse]
 
* RFC 4862 IPv6 Stateless Address Autoconfiguration  [http://www.bortzmeyer.org/4862.html Analyse]
 
* RFC 4862 IPv6 Stateless Address Autoconfiguration  [http://www.bortzmeyer.org/4862.html Analyse]
−
* RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]
+
* RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
 +
* RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes
 
* RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]
 
* RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]
−
* RFC 6106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/6106.html Analyse]
+
* RFC 6275 Mobility Support in IPv6
 +
* RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]
 +
* RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]
 +
* RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]
 +
* RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 +
* RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
 +
* RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]
 +
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]

Latest revision as of 10:58, 15 January 2024


Activité 32: Configurer automatiquement les paramètres de connectivité

Principe de l'auto-configuration

La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) 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.

Route par défaut

La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau "Toutes Directions".

L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants :

  • les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;
  • la longueur du préfixe IP du réseau ;
  • l'adresse du routeur local à utiliser pour la route par défaut ;
  • le serveur de noms à utiliser.

L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP.

L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements "gérés", ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.

Mécanismes mis en œuvre

Avec ou sans état

Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.

L'auto-configuration se déroule en plusieurs étapes mettant en œuvre 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 nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;
  • le nouveau nœud doit ensuite acquérir les informations 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" (IPv6 Stateless Address Autoconfiguration (SLAAC)) [RFC 4862],
    • ou l'auto-configuration "avec état" (par DHCPv6) [RFC 8415] ;
  • les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.
  • enfin, toujours en fonction de la politique de configuration, le nœud 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 nœud 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 nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.

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

À l'initialisation de son interface, le nouveau nœud 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 (tentative) car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud 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. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.

Découverte des paramètres communs au réseau

L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications "inter-liens". La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.

Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :

  • sollicitation d'un routeur, noté RS (Router Solicitation) (voir la figure 1). Ce message ICMPv6 est identifié par le champ type de valeur 133 ;
  • annonce de routeur, noté RA (Router Advertisement) (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ type de valeur 134.
Figure 1 : Format du message de sollicitation d'un routeur.

La sollicitation d'un routeur forme une requête émise par le nœud. 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 nœud demandeur.

Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ adresse source dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse ff02::1. 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 nœuds la présence du ou des routeurs afin de confirmer la connectivité "inter-lien".

Nota : ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, 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 nœud 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 nœuds à détecter une inaccessibilité du routeur.

Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :

  • le bit M (Managed address configuration) mis à 1, indique que le nœud 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" doit être utilisé pour construire une adresse IPv6 ;
  • le bit O (Other stateful configuration) mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.

L'auto-configuration "sans état" pour une adresse IP routable

Le principe de base de l'auto-configuration "sans état" de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 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 nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud é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 nœud ;
  • 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 de préférence, en secondes, pour une adresse construite avec l'auto-configuration "sans état". Pour ce champ et celui de durée de validité, une valeur de 0xffff ffff représente une durée infinie ;
  • 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.

Interprétation du bit L

L'interprétation du bit L à 0 (signifiant implicitement "off-link") a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.

Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état "off-link" d'une adresse est alors significatif.

Au passage, la précaution de forcer le champ "Hop-limit" à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.

L'introduction, dans les infrastructures de type "cloud" de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (data centers) distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.

Comme pour la création de l'adresse "lien-local", l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L"adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). Le préfixe de l'adresse routable 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 nœud 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 8981]. Profitant de la souplesse offerte par IPv6, le nœud 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 la durée préférable écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. 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 à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.


Figure 4 : Durée associée aux états d'une adresse auto-configurée.

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

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 nœud va solliciter le serveur en utilisant le protocole DHCPv6.

Un nœud recevant un message d'annonce de routeur est donc supposé 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 œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.

Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode "non connecté", sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.

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 nœuds repose sur la notion de route directe (ou locale) et de route par défaut.

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 nœud 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 nœud destinataire est localisé sur le même lien. Le nœud é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 nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.

Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.

La découverte 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 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 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (Dynamic Host Configuration) et DNSOP (Domain Name System OPerations). Les co-auteurs des 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.
Une des propositions s'appuie sur des adresses anycast bien connues (Well-known anycast addresses). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.

La première proposition mise en œuvre repose sur le protocole DHCP et l'option DHCPv6 DNS Recursive Name Server spécifiée dans le RFC 3646. Un serveur DHCPv6 dit "sans état" [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression... Depuis, le protocole DHCPv6 pour serveur "avec état" a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.

La seconde proposition, appelée ND RDNSS (Neighbor Discovery Recursive DNS Server), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS.

La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation[2].

La découverte des préfixes de traduction

Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (legacy) localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DNS64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).

En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes :

  • déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;
  • déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements).

Nota : Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les recommendations du RIPE. Par contre Wireshark sait déjà le décoder.


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 nœud et le routeur du lien comme montré par la figure 5.

Figure 5 : Configuration de l'exemple.

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

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 7e bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3e octet, la valeur OxFFFE.

Figure 6 : Procédure DAD.

Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse "multicast sollicitée" associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. 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é : 0x00 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: 33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd|60 00
0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00
0030: 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00 fe 80
0040: 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 nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds 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 7.

Figure 7 : 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é : 0x00 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: 33 33 00 00 00 02 08 00 20 0a aa 6d 86 dd|60 00
0010: 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0a 00
0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00 01 01
0040: 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 et O, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.

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

Le message "Annonce de routeur" est émis vers le groupe de tous les nœuds 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é : 0x00 Label: 000000
 Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0x0ff)
 Source : fe80::1800:20ff:fe0c:7a34 (routeur, lien-local)
 Desti. : ff02::1 (multicast, tous les nœuds du lien)
ICMPv6
 Type : 134 (0x86, Annonce de routeurs) Code : 0 Checksum : 0x8c83
 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)
    Longueur Préfixe : 64 (0x40)
    Drapeaux : L=1, A=1 (0xc)
    Durée de validité : -1 (infinie)
    Durée préférable  : -1 (infinie)
    Préfixe : 2001:db8:12:3::
 
0000: 33 33 00 00 00 01 1a 00 20 0c 7a 34 86 dd|60 00
0010: 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 18 00
0020: 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 01|86 00 8c 83 00 00 17 70 00 00
0040: 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|03 04
0050: 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 20 01
0060: 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 9.

Figure 9 : 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 à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds 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 10 : Les adresses allouées.


Conclusion

L'auto-configuration "sans état" des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.

L'auto-configuration "sans état" a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.

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. ↑ APNIC. Comparison of IPv6 support in operating systems

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

  • RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Analyse
  • RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
  • RFC 4191 Default Router Preferences and More-Specific Routes
  • RFC 4291 IP Version 6 Addressing Architecture Analyse
  • RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches
  • RFC 4861 Neighbor Discovery for IP version 6 (IPv6) Analyse
  • RFC 4862 IPv6 Stateless Address Autoconfiguration Analyse
  • RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
  • RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes
  • RFC 6104 Rogue IPv6 Router Advertisement Problem Statement Analyse
  • RFC 6275 Mobility Support in IPv6
  • RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Analyse
  • RFC 7824 Privacy considerations for DHCPv6 Analyse
  • RFC 7844 Anonymity profile for DHCP clients Analyse
  • RFC 8106 IPv6 Router Advertisement Options for DNS Configuration Analyse
  • RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Analyse
  • RFC 8781 Discovering PREF64 in Router Advertisements Analyse
  • RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 Analyse
Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&oldid=20579"
Personal tools