Difference between revisions of "Protocole de Découverte des voisins"

From Livre IPv6
(→‎En-tête redirigée)
 
(77 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Suivi|Table_des_matières|Début du chapitre|DHCPv6|DHCPv6}}
 +
 
__TOC__
 
__TOC__
 
Le protocole de découverte des voisins ou NDP (''Neighbor Discovery Protocol'') permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.
 
Le protocole de découverte des voisins ou NDP (''Neighbor Discovery Protocol'') permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.
Line 31: Line 33:
 
L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.
 
L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.
  
−
En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'').
+
{{NB-options}}
 +
 
  
  
−
{|
 
−
|+ Utilisation des options dans les messages de découverte des voisins
 
−
| width = 150 |              || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]]  ||width = 100 | [[#NA|annonce]]    ||width = 100 |[[#IR|indication de]]
 
−
|- 
 
−
|              ||  [[#RS|routeur]]        || [[#RA|routeur]]    || [[#NS|d'un voisin]]    || [[#NA|d'un voisin]] || [[#IR|redirection]]
 
−
|-style="background:silver" 
 
−
|[[#physique |adresse physique de la source]]  || présent          || présent    || présent || ||
 
−
|-
 
−
|[[#physique |adresse physique de la cible]]    ||                  ||            ||                || présent    ||  présent
 
−
|-style="background:silver" 
 
−
|[[#information|information sur le préfixe]]    ||                  || ≥ 1 || || ||
 
−
|-
 
−
|[[#redirigee |en-tête redirigée]]    ||                  ||          ||                ||              || présent
 
−
|-style="background:silver" 
 
−
| [[#MTU |MTU]]          ||                  ||  possible || || ||
 
−
|}
 
  
 
== <div id="physique">Adresse physique de la source/cible</div> ==
 
== <div id="physique">Adresse physique de la source/cible</div> ==
  
−
[[image:Fig5-1.png|thumb|right|300px|Figure 5-1 ''Format de l'option adresse physique source/cible'']]
+
<tikz title="Format de l'option adresse physique source/cible">
 +
\clip (0.2, 5.7) rectangle (11.1,6.7);
 +
% \draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=1/2}};
 +
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght }};
 +
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Link Layer Address}};
 +
 +
\draw [draw=white, thick] (addr.north east) -- (addr.south east);
 +
\draw [draw=white, thick] (addr.north east) -- +(-2, 0);
 +
\draw [draw=white, thick] (addr.south east) -- +(-2, 0);
 +
 
 +
\draw [dashed] (addr.north east) -- (addr.south east);
 +
\draw [dashed] (addr.north east) -- +(-2, 0);
 +
\draw [dashed] (addr.south east) -- +(-2, 0);
 +
</tikz>
  
 
La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.
 
La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.
  
 
Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.
 
Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.
 +
 +
Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.
  
 
== <div id="information">Information sur le préfixe</div> ==
 
== <div id="information">Information sur le préfixe</div> ==
  
−
[[image:Fig5-2.png|thumb|right|300px|Figure 5-2 ''Format de l'option information sur le préfixe'']]
+
<tikz title="Format de l'option information sur le préfixe">
 +
\clip (0.2, 2) rectangle (11.1, 7);
 +
% \draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=3}};
 +
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =4 }};
 +
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Prefix Length}};
 +
\draw (7.7, 6) node (bitL) [right, shade, top color=blue!15, bottom color=blue!5,,  draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitL.text) node {\tiny{L}};
 +
\draw (8, 6) node (bitA) [right, shade, top color=blue!15, bottom color=blue!5,,  draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitA.text) node {\tiny{A}};
 +
\draw (8.3, 6) node (bitR) [right, shade, top color=blue!15, bottom color=blue!5,,  draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitR.text) node {\tiny{R}};
 +
\draw (8.6, 6) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=1.5cm] {\tiny{Reserved}};
 +
 
 +
\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Valid Lifetime}};
 +
 
 +
\draw (0.5, 5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefered Lifetime}};
 +
 
 +
\draw (0.5, 4.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};
 +
 +
\draw (0.5, 4) node (addr1) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
 +
\draw (0.5, 3.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
 +
\draw (0.5, 3) node (addr3) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Prefix}};
 +
\draw (0.5, 2.5) node (addr4) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{}};
 +
 
 +
\draw [color=blue!10, very thick] (addr1.south east) --  (addr1.south west);
 +
\draw [color=blue!10, very thick] (addr2.south east) --  (addr2.south west);
 +
\draw [color=blue!10, very thick] (addr3.south east) --  (addr3.south west);
 +
</tikz>
  
 
Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :
 
Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :
Line 78: Line 112:
 
== <div id="redirigee">En-tête redirigée</div> ==
 
== <div id="redirigee">En-tête redirigée</div> ==
  
−
[[image:Fig5-3.png|thumb|right|300px|Figure 5-3 ''Format de l'option en-tête redirigée'']]
+
 
 +
<tikz title="Format de l'option en-tête redirigée">
 +
\clip (0.2, 3.1) rectangle (11.1, 7);
 +
% \draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=4}};
 +
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }};
 +
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};
 +
 
 +
\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};
 +
 
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};
 +
</tikz>
  
 
Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.
 
Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.
Line 87: Line 135:
 
== <div id="MTU">MTU</div> ==
 
== <div id="MTU">MTU</div> ==
  
−
[[image:Fig5-4.png|thumb|right|300px|Figure 5-4 ''Format de l'option MTU'']]
+
 
 +
<tikz title="Format de l'option MTU'">
 +
 
 +
\clip (0.2, 5.1) rectangle (11.1, 7);
 +
% \draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=5}};
 +
\draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{lenght =1 }};
 +
\draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}};
 +
 
 +
\draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{MTU}};
 +
</tikz>
  
 
Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.
 
Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.
Line 93: Line 154:
 
Le champ type vaut 5 et le champ longueur 1.
 
Le champ type vaut 5 et le champ longueur 1.
  
−
= Messages de découverte de voisins =
+
=Messages standards de Découverte des voisins=
 +
 
 +
En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'').
 +
 
 +
{|
 +
|+ Utilisation des options dans les messages de découverte des voisins
 +
| width = 150 |              || width = 100 |[[#RS|sollicitation du]] || width = 100 |[[#RA|annonce du]] || width = 100 |[[#NS|sollicitation]]  ||width = 100 | [[#NA|annonce]]    ||width = 100 |[[#IR|indication de]]
 +
|- 
 +
|              ||  [[#RS|routeur]]        || [[#RA|routeur]]    || [[#NS|d'un voisin]]    || [[#NA|d'un voisin]] || [[#IR|redirection]]
 +
|-style="background:silver" 
 +
|[[#physique |adresse physique de la source]]  || présent          || présent    || présent || ||
 +
|-
 +
|[[#physique |adresse physique de la cible]]    ||                  ||            ||                || présent    ||  présent
 +
|-style="background:silver" 
 +
|[[#information|information sur le préfixe]]    ||                  || &ge; 1 || || ||
 +
|-
 +
|[[#redirigee |en-tête redirigée]]    ||                  ||          ||                ||              || présent
 +
|-style="background:silver" 
 +
| [[#MTU |MTU]]          ||                  ||  possible || || ||
 +
|}
 +
 
  
 
Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.
 
Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.
Line 99: Line 180:
 
== <div id="RS">Sollicitation du routeur</div> ==
 
== <div id="RS">Sollicitation du routeur</div> ==
  
−
[[image:Fig5-5.png|thumb|right|300px|Figure 5-5 ''Format des paquets de sollicitation du routeur'']]
+
<tikz title="Format des paquets de sollicitation du routeur">
 +
\clip (0.2, 3.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=133}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}};
 +
 
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
 +
- Source link-layer address
 +
}};
 +
</tikz>
  
 
Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.
 
Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien <tt>ff02::2</tt>. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.
Line 108: Line 204:
 
== <div id="RA">Annonce du routeur</div> ==
 
== <div id="RA">Annonce du routeur</div> ==
  
−
[[image:Fig5-6.png|thumb|right|300px|Figure 5-6 ''Format des paquets d'annonce du routeur'']]
+
<tikz title="Format des paquets d'annonce du routeur">
 +
\clip (0.2, 1.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=134}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
 +
\draw (0.5, 5.5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Cur. Hop Lim.}};
 +
\draw (2.9, 5.5) node (bitM) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitM.text) node {\tiny{M}};
 +
\draw (3.2, 5.5) node (bitO) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitO.text) node {\tiny{O}};
 +
\draw (3.5, 5.5) node (bitH) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{};\draw (bitH.text) node {\tiny{H}};
 +
\draw (3.8, 5.5) node (res) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=1.5cm]{\tiny{reserved}};
 +
\draw (5.3, 5.5) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Router Lifetime}};
 +
 +
\draw (0.5, 5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reachable Time}};
 +
\draw (0.5, 4.5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Retrans Time}};
 +
 +
\draw (0.5, 3.25) node (context) [right, shade,  top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
 +
Source link-layer address\\
 +
MTU\\
 +
Prefix Information (may be repeated)\\
 +
}};
 +
</tikz>
  
 
Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).
 
Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (<tt>ff02::01</tt>).
Line 128: Line 249:
 
== <div id="NS">Sollicitation d'un voisin</div> ==
 
== <div id="NS">Sollicitation d'un voisin</div> ==
  
−
[[image:Fig5-7.png|thumb|right|300px|Figure 5-7 ''Format des paquets de sollicitation d'un voisin'']]
+
<tikz title="Format des paquets de sollicitation d'un voisin">
 +
 
 +
\clip (0.2, 1.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=135}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
 +
\draw (0.5, 5.5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};
 +
 +
\draw (0.5, 2.25) node (context) [right, shade,  top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
 +
Source link-layer address\\
 +
}};
 +
</tikz>
  
 
Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.
 
Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.
Line 138: Line 277:
 
== <div id="NA">Annonce d'un voisin</div> ==
 
== <div id="NA">Annonce d'un voisin</div> ==
  
−
[[image:Fig5-8.png|thumb|right|300px|Figure 5-8 ''Format des paquets d'annonce d'un voisin'']]
+
<tikz title="Format des paquets d'annonce d'un voisin">
 +
 
 +
\clip (0.2, 1.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=136}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
 +
\draw (0.5, 5.5) node (bitR) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitR.text) node {\tiny{R}};
 +
\draw (0.8, 5.5) node (bitS) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitS.text) node {\tiny{S}};
 +
\draw (1.1, 5.5) node (bitO) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=.3cm]{}; \draw (bitO.text) node {\tiny{O}};
 +
\draw (1.4, 5.5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=8.7cm]{\tiny{Reserved}};
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};
 +
 +
\draw (0.5, 2.25) node (context) [right, shade,  top color=blue!15, bottom color=blue!5, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
 +
Source link-layer address\\
 +
}};
 +
</tikz>
  
 
Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.
 
Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.
Line 150: Line 310:
 
== <div id="IR">Indication de redirection</div> ==
 
== <div id="IR">Indication de redirection</div> ==
  
−
La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).
+
<tikz title="Format des paquets d'indication de redirection">
 +
\clip (0.2, 0) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
  
−
[[image:Fig5-9.png|thumb|right|300px|Figure 5-9 ''Format des paquets d'indication de redirection'']]
+
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=137}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
 
 +
\draw (0.5, 5.5) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Reserved}};
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Target Address}};
 +
 +
\draw (0.5, 2.25) node (context) [right, shade,  top color=blue!50, bottom color=blue=!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Destination Address}};
 +
 +
 +
\draw (0.5, 0.5) node (context) [right, shade,  top color=blue!15, bottom color=blue!5, draw, minimum height=1.5cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Options:\\
 +
Target link-layer address\\
 +
Redirected Header\\
 +
}};
 +
</tikz>
 +
 
 +
La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).
  
 
Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.
 
Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.
Line 164: Line 345:
  
 
Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.
 
Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.
 +
 +
Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.
 +
 +
IPv6 utilise aussi ce message pour optimiser la résolution Hors-Lien dans le [[#Cas des réseaux NBMA|cas de réseaux NBMA]].
  
 
=Configuration automatique=
 
=Configuration automatique=
−
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et source d'erreurs. Avec IPv6, cette configuration est automatisée, introduisant par là-même des caractéristiques de fonctionnement immédiat (''plug and play'') à l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous allons maintenant étudier l'autre aspect de l'autoconfiguration de IPv6 qui est l'autoconfiguration d'adresses. Celle-ci a pour objectif :
+
Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et source d'erreurs. Avec IPv6, cette configuration est automatisée, introduisant ainsi des caractéristiques de fonctionnement immédiat (''plug and play'') de l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous allons maintenant étudier l'autre aspect de l'auto-configuration de IPv6 qui est l'auto-configuration d'adresses. Celle-ci a pour objectif :
  
 
* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
 
* l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
 
* la possibilité d'attribuer d'autres préfixes, voire de renuméroter une machine.
 
* la possibilité d'attribuer d'autres préfixes, voire de renuméroter une machine.
  
−
Le processus d'autoconfiguration d'adresse d'IPv6 comprend la création d'une adresse lien-local, l'attachement aux groupes de multicast sollicités, la vérification de l'unicité de l'adresse lien-local et la construction d'adresses unicast globales.  
+
Le processus d'auto-configuration d'adresse d'IPv6 comprend la création d'une adresse lien-local, l'attachement aux groupes de multicast sollicités, la vérification de l'unicité de l'adresse lien-local et la construction d'adresses unicast globales.  
  
−
Le rôle du routeur est important dans l'autoconfiguration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'autoconfiguration d'adresse se décompose de la manière suivante :
+
Le rôle du routeur est important dans l'auto-configuration. Il dicte à la machine, par des bits (cf. [[Découverte de voisins#RA|Annonce du routeur]]) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit <tt>M</tt> (''Managed address configuration'') mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit <tt>O</tt> (''Other stateful configuration'') indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'auto-configuration d'adresse se décompose de la manière suivante :
  
 
* La toute première étape consiste à créer l'adresse lien-local.
 
* La toute première étape consiste à créer l'adresse lien-local.
Line 179: Line 364:
 
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
 
* La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
 
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
 
* S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
−
** l'autoconfiguration sans état,
+
** l'auto-configuration sans état,
−
** l'autoconfiguration avec état.
+
** l'auto-configuration avec état.
−
* En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'autoconfiguration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.
+
* En l'absence de routeur sur le lien, la machine 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. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.
 +
 
 +
==Cycle de vie d'une adresse==
 +
 +
Comme IPv6 généralise le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs et ne peuvent plus être attribués "à vie" aux équipements. Pour faciliter la renumérotation d'une machine, l'attribution d'une adresse à une interface n'est faite que pour un temps limité ; les adresses IPv6 ne sont pas données mais prêtées. Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide pour cette interface, et peut être assignée à une autre interface. Une adresse invalide ne doit jamais être utilisée comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30 jours, mais cette durée peut être prolongée, ou portée à l'infini. L'adresse lien-local a une durée de vie illimitée.
 +
 
 +
<tikz title="États successifs d'une adresse sur une interface">
 +
 +
\draw [thick, ->] (0,2) -- (9.5,2);
 +
 +
\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
 +
\draw (1, 2) node [rectangle, minimum width=1cm, minimum height=1cm, fill, left color=black!10,  right color=black!20, draw=black, above right]  (tentative) {};
 +
\draw (tentative.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=green,  right color=green!50, draw=black, above right]  (preferred) {};
 +
\draw (preferred.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right]  (deprecated) {};
 +
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right]  (novalid) {};
 +
 +
 
 +
\draw (tentative.text) node {\tiny{Tentative}};
 +
\draw (preferred.text) node {\tiny{Preferred}};
 +
\draw (deprecated.text) node {\tiny{Deprecated}};
 +
\draw (novalid.text) node {\tiny{Invalid}};
 +
 +
\draw [dotted] (tentative.south west) -- +(0, -1);
 +
\draw [dotted] (preferred.south west) -- +(0, -1);
 +
\draw [dotted] (deprecated.south west) -- +(0, -1);
 +
\draw [dotted] (novalid.south west) -- +(0, -1);
 +
 +
\draw [dashed, <->] ([yshift=-0.5cm]tentative.south west) -- node [above] {\tiny{DAD}} ([yshift=-0.5cm] preferred.south west) ;
 +
 
 +
\draw [dashed, <->] ([yshift=-0.5cm]preferred.south west) -- node [above] {\tiny{Valid}} ([yshift=-0.5cm] novalid.south west) ;
 +
 
 +
 
 +
</tikz>
 +
 
 +
La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse, sinon toutes les communications TCP, qui l'utilisent comme identificateur de connexion, seraient immédiatement coupées. Ceci entraînerait des perturbations importantes au niveau des applications.
 +
 
 +
Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses valides à une même interface. Ensuite, pour effectuer le choix de l'adresse à utiliser, un état lui est associé. Il indique dans quelle phase de sa durée de vie une adresse se situe vis à vis de l'interface. Le premier de ces états est qualifié de ''préféré'' : l'utilisation n'est aucunement restreinte. Peu avant son invalidation, l'adresse passe dans l'état ''déprécié''. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée ne doit plus être utilisée comme adresse source pour les nouvelles communications (comme l'établissement de connexion TCP). Par contre, l'adresse dépréciée peut encore servir d'adresse source dans le cas des communications existantes. Les paquets reçus à une adresse dépréciée continuent à être remis normalement.  Le contrôle de la durée de chaque état d'une adresse valide est effectué en ajoutant une durée de vie à l'état préféré.
 +
La figure '''États successifs d'une adresse sur une interface''' représente les différents états que prend une adresse lorsqu'elle est allouée à une interface.
  
 
==Création de l'adresse lien-local==
 
==Création de l'adresse lien-local==
  
−
À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est de marier un préfixe avec l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'autoconfiguration s'arrête et une intervention manuelle est nécessaire.
+
<tikz title="Création de l'adresse lien-local">
 +
\clip (0, 0) rectangle (10,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);
 +
 +
\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);
 +
 
  
−
Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'autoconfiguration est achevée.
+
\draw (1.5,4.5) node {\small{FE80::IID1}};
 +
\draw (1.5,4) node {\small{$\alpha$::IID1/64}};
 +
 
 +
\draw (8, 4.5) node {\small{FE80::IID2}};
 +
 +
</tikz>
 +
À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse [[Identifiant_d'interface#EUI-64|EUI-64]]. Le principe de base de la création d'adresse IPv6 est d'associer un préfixe à l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (<tt>FE80::/64</tt>) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.
 +
 
 +
Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'auto-configuration est achevée.
  
 
==<div id="DAD"> Détection d'adresse dupliquée </div>==
 
==<div id="DAD"> Détection d'adresse dupliquée </div>==
  
−
Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'autoconfiguration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :
+
<tikz title="Emission d'un NS lors d'un DAD">
 +
\clip (0, 0) rectangle (10,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);
 +
 +
\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);
 +
 
 +
\draw (7.8, 5) -- (7.8, 3.2);
 +
\draw [<->] (1, 3.2) --  node [above] {\tiny{::/0 -$>$ solicited (FE80:IID2) : NS (who has FE80::IID2?)}}(9, 3.2) ;
 +
 
 +
</tikz>
 +
Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 [[Découverte de voisins#NS|sollicitation d'un voisin]] et [[Découverte de voisins#NA|annonce d'un voisin]]. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :
  
 
* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
 
* Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
Line 199: Line 456:
 
A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.
 
A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.
  
−
== Autoconfiguration sans état ==
+
== Auto-configuration sans état ==
  
−
L'autoconfiguration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'autoconfiguration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.
+
<tikz title="Emission d'un RS">
 +
\clip (0, 0) rectangle (10,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);
 +
 +
\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);
 +
 
 +
\draw (7.8, 5) -- (7.8, 3.2);
 +
\draw [<->] (1, 3.2) --  node [above] {\tiny{FE80::IID2 -$>$ FF02::2 : RS }} (9, 3.2) ;
 +
 +
</tikz>
  
−
Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par autoconfiguration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.
+
 
 +
 
 +
L'auto-configuration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'auto-configuration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
<tikz title="Réception d'un RA">
 +
\clip (0, 0) rectangle (10,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,3)--(9,3);
 +
 +
\pgfputat{\pgfxy(0.8,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,5)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,3)--(1.5,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,3)--(8,5);
 +
 
 +
\draw [->] (1.7,5) -- (1.7, 3.2) -- node [above = 10pt] {\tiny{FE80::IID1 -$>$ FE80::IID2}}  node [above] {\tiny{RA ($\alpha$::/64, DHCPv6, MTU=1500, HL=64, {bit {\tt M=1}) }}}  (7.8, 3.2) -- (7.8, 5);
 +
 
 +
</tikz>
 +
 
 +
 
 +
Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par auto-configuration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.
  
 
La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
 
La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.
 +
 +
 +
===Cas des réseaux NBMA===
 +
 +
<tikz title="Off Link NDP: première étape">
 +
\clip (0, 0) rectangle (11,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
          \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
       
 +
\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [above, color=black] {\tiny{FE80::IID2 -$>$ FF02::2 : RS}} (5,5);
 +
 
 +
</tikz>
 +
 +
Les réseaux NBMA (''Non Broadcast Multiple Access'') ne donnent pas la possibilité de diffusion de tous vers tous, ce qui conduit à deux comportements possibles :
 +
* absence totale de diffusion, comme dans les réseaux publics (téléphonique, ATM,...) où un seul correspondant peut être joint à la fois ;
 +
* possibilité de diffusion par un nombre restreint d'équipements, comme par exemple les réseaux radio de type 3G, WiMAX où la station de base a la possibilité de diffuser des données vers tous les équipements tandis que l'inverse n'est pas possible.
 +
 +
<tikz title="Off Link NDP: Deuxième étape">
 +
\clip (0, 0) rectangle (11,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
          \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
    \draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5, 5)-- node [above, color=black] {\tiny{RA ($\alpha$::/64, DHCPv6, OffLink, MTU=1500, HL=64, {bit {\tt M=1}})}} (8,3);
 +
 +
</tikz>
 +
 +
Le comportement en réseau NBMA peut également servir à réduire les contraintes énergétiques. En effet, par exemple dans le cas des réseaux de capteurs, le multicast/broadcast est couteux en énergie puisque tous les équipements vont devoir traiter le message et certains devront le retransmettre.
 +
 +
<tikz title="Off Link NDP: Troisième étape">
 +
\clip (0, 0) rectangle (11,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
          \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
   
 +
\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near start, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);         
 +
 
 +
\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);         
 +
 
 +
</tikz>
 +
 +
Pour ces cas de figure, le protocole de découverte de voisins possède un mode NBMA appelé également ''OffLink'' qui n'autorise le dialogue qu'avec un routeur. Les échanges commencent de la même manière :
 +
* l'équipement qui souhaite s'insérer dans le réseau, émet en utilisant l'adresse de destination FF02::2 (tous les routeurs du lien), un message RS (Router Sollicitation). Le réseau NBMA devant envoyer ce message vers un routeur.
 +
* Le routeur répond en positionnant le bit <tt>L</tt> (OffLink) à 1 dans l'option [[#information|Information sur le préfixe]], indiquant que tous les échanges devront passer par lui.
 +
* L'équipement construit son adresse globale en concaténant le préfixe à son identifiant d'interface.
 +
* L'équipement envoie systématiquement tous les paquets à l'adresse physique du routeur et celui-ci qui a une vision globale du réseau les réémet vers le bon destinataire.
 +
<tikz title="Off Link NDP: Quatrième étape (optionnelle)">
 +
\clip (0, 0) rectangle (11,7);
 +
% \draw[help lines] (0,0) grid (10,7 );
 +
 +
\pgfputat{\pgfxy(4.5,5)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
          \pgfputat{\pgfxy(7.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
          \pgfputat{\pgfxy(1.5,2)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
   
 +
\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (8,3)-- node [left, near end, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (5,5);         
 +
 
 +
\draw[decorate,decoration={zigzag}, color=black!60, ->, very thick] (5,5)-- node [left, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);         
 +
         
 +
          \draw[decorate,decoration={triangles}, color=black!60, ->, thick, ] (5,5) to [bend left] node [right, near start, color=black] {\tiny{REDIRECT $\alpha$::IID3 : MAC3}} (8,3);         
 +
 +
\draw [color=black!60, ->, very thick, dotted] (8,3)-- node [above, midway, color=black] {\tiny{$\alpha$::IID2 -$>$ $\alpha$::IID3 : DATA}} (2,3);         
 +
     
 +
 +
</tikz>
 +
 +
* Si la technologie du lien le permet et si la politique de gestion du réseau l'autorise, le routeur a la possibilité d'optimiser le trafic en information l'équipement de la véritable adresse du destinataire. Le routeur émet un message d'[[#IR|indication de redirection]] (''ICMP Redirect'') pour informer l'équipement de l'adresse physique du destinataire. Les paquets suivants ne transiteront plus par le routeur central.
 +
 +
===Cas des réseaux Mobiles===
 +
 +
La duplication d'adresses est un processus relativement long puisqu'un équipement qui souhaite garantir l'unicité de son adresses doit être un message NS et attendre une absence de réponse. De plus, comme le réseau peut perdre les messages NS, un équipement peut tenter plusieurs fois de résoudre sa propre adresse avant de la garantir unique. Finalement, le processus se répète pour l'adresse lien-local et l'adresse globale. Il faut donc plusieurs secondes avant qu'un équipement puisse envoyer des paquets sur le réseau. En situation de mobilité, ce délai qui s'ajoute à ceux de la découverte des réseaux disponibles et à l'authentification, peut conduire à des ruptures de connectivité (par exemple pour la voix sur IP).
 +
 +
Le RFC 4429 rend plus tolérant la détection d'adresse dupliquée en autorisant un site à utiliser son adresse bien qu'elle n'ait pas été encore garantie unique. Ce comportement est appelé DAD optimiste (''optimistic DAD''). L'état tentative de l'adresse (voir [[#Cycle de vie d'une adresse|Cycle de vie d'une adresse]] est remplacé par l'état optimiste pendant lequel l'unicité de l'adresse n'est pas garanti mais qui permet son utilisation. En parallèle, un DAD classique est lancé. les messages NS sont émis avec le bit O (Override) à 0 pour que les caches ND ne soit pas mis à jour au cas où cette adresse existerait déjà sur le réseau.
 +
 +
==Découverte du MTU==
 +
 +
<tikz title="Découverte du MTU première phase : envoi d'un paquet trop grand">
 +
\clip (0, 0) rectangle (11,8);
 +
%\draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
 +
 +
\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
 +
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
\draw (8, 3.6) node {\small{A}};
 +
\draw (5.5, 6.6) node {\small{B}};
 +
\draw (1.5, 3.6) node {\small{R}};
 +
 +
\draw (1.5,1.5) node {\small{MTU=1500}};
 +
\draw (1.5,5.5) node {\small{MTU=1280}};
 +
 +
\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
 +
 +
 +
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1500}} (7.8, 2.2) -- (7.8, 3);
 +
}
 +
</tikz>
 +
 +
Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou ''Path Maximum Transmission Unit ''(unité de transfert de taille maximale sur le chemin).
 +
 +
 +
Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché. S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand», en y indiquant le MTU accepté. Fort de ces informations, l'équipement émetteur réduit le PMTU supposé pour ce chemin.
 +
 +
Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple).
 +
<tikz title="Découverte du MTU seconde phase: reception d'un message ICMPv6">
 +
\clip (0, 0) rectangle (11,8);
 +
%\draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
 +
 +
\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
 +
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
\draw (8, 3.6) node {\small{A}};
 +
\draw (5.5, 6.6) node {\small{B}};
 +
\draw (1.5, 3.6) node {\small{R}};
 +
 +
\draw (1.5,1.5) node {\small{MTU=1500}};
 +
\draw (1.5,5.5) node {\small{MTU=1280}};
 +
 +
\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
 +
 +
 +
 +
\draw [->] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{R-$>$ A ICMP6 Error: Packet too big}} node [above] {\tiny{MTU=1280}} (7.8, 2.2) -- (7.8, 3);
 +
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
 +
 +
</tikz>
 +
 +
Si la détermination du PMTU se fait essentiellement lors des premiers échanges entre les équipements concernés, elle peut également être revue en cours de transfert si, suite à un changement de route, un lien plus contraignant est traversé.
 +
 +
L'émetteur vérifie aussi que le PMTU n'a pas augmenté en envoyant de temps en temps un paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est augmentée.
 +
 +
Signalons enfin que l'algorithme de découverte du PMTU fonctionne indifféremment avec des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU minimal autorisé par l'ensemble des chemins vers chaque site destinataire du groupe de diffusion.
 +
 +
 +
 +
L'exploitation de l'information de PMTU se fait de plusieurs façons suivant l'endroit où les données à transmettre sont segmentées :
 +
 +
* si un protocole de type TCP est utilisé, celui-ci assurera la segmentation de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6.
 +
* si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci
 +
** (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et
 +
** (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir [[IPv6_QO#Fragmentation|fragmentation]]).
 +
<tikz title="Découverte du MTU troisième phase: Emission d'un paquet de taille correcte">
 +
\clip (0, 0) rectangle (11,8);
 +
%\draw[help lines] (0,0) grid (10,7 );
 +
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,2)--(9,2);
 +
 +
\pgfputat{\pgfxy(0.8,3)}{\pgfbox[left,base]{\pgfuseimage{router}}}
 +
\pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,2)--(1.5,3);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,2)--(8,3);
 +
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (1.5,4)--(1.5,5);
 +
\draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,5)--(9,5);
 +
\draw[line width=0.15cm,color=red!30,cap=round,join=round] (5.5,5)--(5.5,6);
 +
\pgfputat{\pgfxy(5,6)}{\pgfbox[left,base]{\pgfuseimage{compleft}}}
 +
\draw (8, 3.6) node {\small{A}};
 +
\draw (5.5, 6.6) node {\small{B}};
 +
\draw (1.5, 3.6) node {\small{R}};
 +
 +
\draw (1.5,1.5) node {\small{MTU=1500}};
 +
\draw (1.5,5.5) node {\small{MTU=1280}};
 +
 +
\draw (9.5, 3.5) node {\tiny{PMTU(*)=1500}};
 +
\draw (9.5, 3) node {\alert{\tiny{PMTU(B)=1280}}};
 +
\draw [<-] (1.7,3) -- (1.7, 2.2) -- node [above = 10pt] { \tiny{A-$>$ B Size=1280}} (7.8, 2.2) -- (7.8, 3);
 +
\draw [->] (1.7,4) -- (1.7, 4.8) -- (5.3, 4.8) -- (5.3, 6);
 +
</tikz>
 +
Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à la discrétion de l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir [[Les extensions#Routage|routage]]).
 +
 +
Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets.
 +
{{Suivi|Table_des_matières|Début du chapitre|DHCPv6|DHCPv6}}

Latest revision as of 22:12, 19 April 2022

Début du chapitre Table des matières DHCPv6

Le protocole de découverte des voisins ou NDP (Neighbor Discovery Protocol) permet à un équipement de s'intégrer dans l'environnement local, c'est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs). Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6 (voir Valeurs des champs type et code d'ICMPv6). Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255. Cette valeur sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversée un routeur. Les datagramme ayant une valeur différent de 255 doivent être ignorés par le récepteur.

Valeurs des champs type et code d'ICMPv6
type code nature
Gestion des erreurs
1 Destination inaccessible :
0 * aucune route vers la destination
1 * la communication avec la destination est administrativement interdite
2 * hors portée de l'adresse source
3 * l'adresse est inaccessible
4 * le numéro de port est inaccessible
5 * l'adresse source est filtrée par un firewall
6 * l'adresse destination est rejetée
2
3 Temps dépassé :
0 * limite du nombre de sauts atteinte
1 * temps de réassemblage dépassé
4 Erreur de paramètre :
0 * champ d'en-tête erroné
1 * champ d'en-tête suivant non reconnu
2 * option non reconnue
Information
128 Demande d'écho
129 Réponse d'écho
Gestion des groupes multicast (MLD, RFC 2710)
130 Requête d'abonnement
131 Rapport d'abonnement
132 Fin d'abonnement
Découverte de voisins (RFC 2461)
133 Sollicitation du routeur
134 Annonce du routeur
135 Sollicitation d'un voisin
136 Annonce d'un voisin
137 Redirection
Renumérotation des routeurs (expérimental, RFC 2894)
138
Renumérotation des routeurs :
0 * Commande
1 * Résultat
255 * Remise à zéro du numéro de séquence
Recherche d'information sur un noeud (expérimental)
139 Demande d'information
140 Réponse
Découverte de voisins inverse (RFC 3122)
141 Sollicitation
142 Annonce
Gestion des groupes multicast (MLDv2, RFC 3810)
143 Rapport d'abonnement MLDv2
Mobilité (RFC 3775)
144 Découverte d'agent mère (requête)
145 Découverte d'agent mère (réponse)
146 Sollicitation de préfixe mobile
147 Annonce de préfixe mobile
Découverte de voisins sécurisée (SEND, RFC 3971)
148 Sollicitation de chemin de certification
149 Annonce de chemin de certification
Mobilité (expérimental)
150 Protocoles de mobilité expérimentaux, tels que Seamoby

Le protocole réalise les différentes fonctions :

  • Résolution d'adresses. Le principe est très proche du protocole ARP que l'on trouve avec IPv4. La principale différence vient de l'emploi de messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3. Cela confère une plus grande souplesse d'utilisation en particulier sur les réseaux qui ne supportent pas la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.
  • Détection d'inaccessibilité des voisins ou NUD (Neighbor Unreachability Detection). Cette fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse,...). Si un routeur devient inaccessible, la table de routage peut être modifiée pour prendre en compte une autre route.
  • Configuration. La configuration automatique des équipements est l'un des attraits principaux d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en oeuvre :
    • Découverte des routeurs. Ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le protocole ICMP Router Discovery.
    • Découverte des préfixes. L'équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de l'équipement, celui-ci construit son ou ses adresses IPv6. Il n'existe pas d'équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l'auto-configuration.
    • Détection des adresses dupliquées. Comme les adresses sont construites automatiquement, il existe des risques d'erreurs en cas d'identité de deux identifiants. Ce protocole teste qu'aucun autre équipement sur le lien ne possède la même adresse IPv6. Cette fonctionnalité est une évolution de l'ARP gratuit d'IPv4 émis à l'initialisation de l'interface.
    • Découverte des paramètres. Ce protocole permet aux équipements d'apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme DHCPv6) est active... Il n'existe pas d'équivalent en IPv4.
  • Indication de redirection. Ce message est utilisé quand un routeur connaît une route meilleure (en nombre de sauts) pour aller à une destination.
En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses correspondant aux réseaux locaux.
Avec IPv6, la correspondance entre préfixe et réseau local est moins stricte. Il est prévu qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens (une généralisation du modèle des réseaux logiques d'IP sur ATM). Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection pour que la suite du dialogue se fasse directement (cf. exemples Indication de redirection).
Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement peut être configuré pour dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer l'équipement des destinataires sur le même lien.

IPv6 spécifie deux méthodes d'autoconfiguration pour l'adresse unicast globale :

  • l'autoconfiguration sans état (stateless autoconfiguration, RFC 2462) ; elle est utilisée quand la gestion administrative des adresses attribuées n'est pas nécessaire au sein d'un site. Ces mécanismes sont décrits dans la suite de ce chapitre.
  • l'autoconfiguration avec état (stateful autoconfiguration) ; elle est retenue lorsqu'un site demande un contrôle strict de l'attribution des adresses (cf. DHCPv6).

Mais l'utilisation de DHCPv6 pour obtenir l'adresse est pilotée par le protocole de découverte des voisins.

Données véhiculées par les messages

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier la plupart des données utilise un format d'options commun, ce qui simplifie la mise en oeuvre du protocole. Le format contient les champs type, longueur en mots de 64 bits, données. La faible précision du champ longueur va introduire une perte de place. En contre-partie, elle va permettre aussi un alignement des options sur des mots de 64 bits, ce qui optimise leur traitement.

type description Message
Basic Neighbor Discovery options [RFC 4861]
1 Source Link-layer Address (SLLAO) RS/RA/NS
2 Target Link-layer Address NA/Redirect
3 Prefix Information (PIO) RA
4 Redirected Header Redirect
5 MTU RA
NBMA (unused) [RFC 2491]
6 NBMA Shortcut Limit Option NS
Mobile IP [RFC 6275]
7 Advertisement Interval Option RA
8 Home Agent Information Option RA
9 Source Address List
10 Target Address List
SEND [RFC 3971]
11 CGA option
12 RSA Signature option
13 Timestamp option
14 Nonce option
15 Trust Anchor option
16 Certificate option
Mobility options
17 IP Address/Prefix Option [RFC 5568]
18 New Router Prefix Information Option [RFC 5568]
19 Link-layer Address Option [RFC 5568]
20 Neighbor Advertisement Acknowledgment Option [RFC 5568]
23 MAP Option [RFC 5380]
SLAAC optimization
24 Route Information Option [RFC 4191]
25 Recursive DNS Server Option [RFC 8106] RA
26 RA Flags Extension Option [RFC 5175]
Fast Mobility options
27 Handover Key Request Option [RFC 5269]
28 Handover Key Reply Option [RFC 5269]
29 Handover Assist Information Option [RFC 5271]
30 Mobile Node Identifier Option [RFC 5271]
6LoWPAN [RFC 6775]
33 Address Registration (ARO)
34 6LoWPAN Context (6CO)
35 Authoritative Border Router (ABRO)
38 PREF64 [RFC 8781] RA
157 Duplicate Address Request (DAR)
158 Duplicate Address Confirmation (DAC)
Inverse Neighbor Discovery [RFC 3122]
138 CARD Request option [RFC 4065]
139 CARD Reply option [RFC 4065]



Adresse physique de la source/cible

Format de l'option adresse physique source/cible
Figure : Format de l'option adresse physique source/cible

La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.

Information sur le préfixe

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

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Le champ type vaut 3 et le champ longueur vaut 4. La figure Format de l'option information sur le préfixe donne le format de l'option :

  • Le champ lg.préfixe indique combien de bits sont significatifs pour le préfixe annoncé dans un champ suivant.
  • Le bit L indique, quand il est à 1, que le préfixe permet d'indiquer que tous les autres équipements partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, l'équipement émet le paquet vers le routeur. Si ce dernier sait que l'équipement émetteur peut joindre directement le destinataire, il émettra un message ICMPv6 d'indication de redirection.
  • Le bit A indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse de l'équipement.
  • Le bit R, indique, quand il est à 1, que le champ préfixe contient l'adresse globale d'un routeur «agent mère». Les bits de poids fort peuvent toujours être utilisés pour construire un préfixe.
  • Le champ durée de validité indique en secondes la durée pendant laquelle le préfixe est valide.
  • Le champ durée préférable indique la durée en secondes pendant laquelle une adresse construite avec le protocole de configuration sans état demeure «préférable» (cf. Durée de vie des adresses).

Pour ces deux champs, une valeur de 0xffffffff représente une durée infinie. Ces champs peuvent servir dans la phase de passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.

  • Le champ réservé permet d'aligner le préfixe sur une frontière de mot de 64 bits.
  • Le champ 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.

En-tête redirigée

### &lt;math_failure&gt; (math_image_error - &lt;math_image_error&gt;): \clip (0.2, 3.1) rectangle (11.1, 7); % \draw[help lines] (0,0) grid (11,6); \draw (0.5, 6.5) node [right] {\tiny{\tt{0..................7...................15...................23....................31}}}; \draw (0.5, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type=4}}; \draw (2.9, 6) node (context) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{length =1 }}; \draw (5.3, 6) node (addr) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Reserved}}; \draw (0.5, 5.5) node (addr2) [right, shade, top color=blue!15, bottom color=blue!5, draw, minimum height=0.5cm, minimum width=9.6cm] {\tiny{Reserved}}; \draw (0.5, 4.25) node (context) [right, shade, top color=purple!50, bottom color=purple!10, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{IPv6 Header and Data}};


Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.


Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

MTU

Format de l'option MTU'
Figure : Format de l'option MTU'

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

Messages standards de Découverte des voisins

En plus des cinq options générales décrites dans le tableau Utilisation des options dans les messages de découverte des voisins, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (Non Broadcast Multiple Access).

Utilisation des options dans les messages de découverte des voisins
sollicitation du annonce du sollicitation annonce indication de
routeur routeur d'un voisin d'un voisin redirection
adresse physique de la source présent présent présent
adresse physique de la cible présent présent
information sur le préfixe ≥ 1
en-tête redirigée présent
MTU possible


Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et un dernier pour la redirection. Chacun de ces messages peut contenir des options.

Sollicitation du routeur

Format des paquets de sollicitation du routeur
Figure : Format des paquets de sollicitation du routeur

Le message de sollicitation d'un routeur (cf. figure Format des paquets de sollicitation du routeur) est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l'adresse IPv6 de multicast réservée aux routeurs sur le même lien ff02::2. Si l'équipement ne connaît pas encore son adresse source, l'adresse non spécifiée est utilisée.


Le champ option contient normalement l'adresse physique de l'équipement.

Annonce du routeur

Format des paquets d'annonce du routeur
Figure : Format des paquets d'annonce du routeur

Ce message (cf. figure Format des paquets d'annonce du routeur) est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d'un routeur par un équipement. Le champ adresse source contient l'adresse locale au lien du routeur, le champ destination contient soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse de toutes les stations (ff02::01).

Un champ saut max. non nul donne la valeur qui pourrait être placée dans le champ nombre de sauts des paquets émis. Le bit M indique qu'une adresse de l'équipement doit être obtenue avec un protocole de configuration (cf. Configuration avec état :DHCPv6). Le bit O indique aussi la présence d'un service de configuration mais pour la récupération d'informations autres que l'adresse. Si l'adresse ne peut être obtenue d'un serveur, l'équipement procède à une configuration sans état en concaténant aux préfixes qu'il connaît son identifiant d'interface. Le bit H indique que le routeur peut être utilisé comme «agent mère» pour un noeud mobile (cf. Avertissement de l'agent mère).

Le champ durée de vie du routeur donne, en secondes, la période pendant laquelle l'équipement annonçant effectuera les fonctions de routeur par défaut. La valeur maximale correspond à 18 heures 12 minutes, mais comme ce message est émis périodiquement il n'y a pas de limite théorique à la durée de vie d'un routeur. Une valeur de 0 indique que l'équipement ne remplit pas les fonctions de routeur par défaut. Cette durée de vie ne s'applique pas aux options que ce message véhicule.

Le champ durée d'accessibilité indique la durée en millisecondes pendant laquelle une information contenue dans le cache de la machine peut être considérée comme valide (par exemple, la table de correspondance entre adresse IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité est émis pour vérifier la pertinence de l'information.

Le champ temporisation de retransmission donne en millisecondes la période entre deux émissions non sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du routeur.

Ce message peut véhiculer les options :

  • adresse physique de la source,
  • MTU,
  • information sur le préfixe (une ou plus).

Sollicitation d'un voisin

Format des paquets de sollicitation d'un voisin
Figure : Format des paquets de sollicitation d'un voisin

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, soit une adresse globale, soit l'adresse non spécifiée. Le champ destination contient soit l'adresse de multicast sollicité correspondant à l'adresse recherchée (cf. Identifiant de groupe), soit l'adresse de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

Annonce d'un voisin

Format des paquets d'annonce d'un voisin
Figure : Format des paquets d'annonce d'un voisin

Ce message (cf. figure Format des paquets d'annonce d'un voisin) est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut «routeur». Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

  • Le bit R est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
  • Le bit S mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
  • Le bit O mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
  • Le champ adresse de la cible contient, si le bit S est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit S est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
  • L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

Indication de redirection

Format des paquets d'indication de redirection
Figure : Format des paquets d'indication de redirection

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

La figure Format des paquets d'indication de redirection donne le format du message :

  • Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
  • Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.

IPv6 utilise aussi ce message pour optimiser la résolution Hors-Lien dans le cas de réseaux NBMA.

Configuration automatique

Traditionnellement, la configuration d'une interface réseau d'une machine demande une configuration manuelle. C'est un travail souvent long et source d'erreurs. Avec IPv6, cette configuration est automatisée, introduisant ainsi des caractéristiques de fonctionnement immédiat (plug and play) de l'interface réseau. La configuration automatique signifie qu'une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de "spécialiste". Nous allons maintenant étudier l'autre aspect de l'auto-configuration de IPv6 qui est l'auto-configuration d'adresses. Celle-ci a pour objectif :

  • l'acquisition d'une adresse quand une machine est attachée à un réseau pour la première fois ;
  • la possibilité d'attribuer d'autres préfixes, voire de renuméroter une machine.

Le processus d'auto-configuration d'adresse d'IPv6 comprend la création d'une adresse lien-local, l'attachement aux groupes de multicast sollicités, la vérification de l'unicité de l'adresse lien-local et la construction d'adresses unicast globales.

Le rôle du routeur est important dans l'auto-configuration. Il dicte à la machine, par des bits (cf. Annonce du routeur) de l'en-tête du message d'annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. Le bit M (Managed address configuration) mis à 1 indique que l'équipement ne doit pas construire lui-même l'adresse à partir de son identifiant d'interface et des préfixes reçus, mais doit explicitement demander son adresse auprès d'une application d'un serveur d'adresses. Le bit O (Other stateful configuration) indique que l'équipement doit interroger le serveur de configuration pour obtenir des paramètres autre que l'adresse. L'algorithme de la procédure d'auto-configuration d'adresse se décompose de la manière suivante :

  • La toute première étape consiste à créer l'adresse lien-local.
  • Une fois l'unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.
  • La machine doit chercher à acquérir un message d'annonce du routeur pour déterminer la méthode d'obtention de l'adresse unicast globale.
  • S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :
    • l'auto-configuration sans état,
    • l'auto-configuration avec état.
  • En l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration avec état. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

Cycle de vie d'une adresse

Comme IPv6 généralise le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs et ne peuvent plus être attribués "à vie" aux équipements. Pour faciliter la renumérotation d'une machine, l'attribution d'une adresse à une interface n'est faite que pour un temps limité ; les adresses IPv6 ne sont pas données mais prêtées. Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide pour cette interface, et peut être assignée à une autre interface. Une adresse invalide ne doit jamais être utilisée comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30 jours, mais cette durée peut être prolongée, ou portée à l'infini. L'adresse lien-local a une durée de vie illimitée.

États successifs d'une adresse sur une interface
Figure : États successifs d'une adresse sur une interface

La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse, sinon toutes les communications TCP, qui l'utilisent comme identificateur de connexion, seraient immédiatement coupées. Ceci entraînerait des perturbations importantes au niveau des applications.

Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses valides à une même interface. Ensuite, pour effectuer le choix de l'adresse à utiliser, un état lui est associé. Il indique dans quelle phase de sa durée de vie une adresse se situe vis à vis de l'interface. Le premier de ces états est qualifié de préféré : l'utilisation n'est aucunement restreinte. Peu avant son invalidation, l'adresse passe dans l'état déprécié. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée ne doit plus être utilisée comme adresse source pour les nouvelles communications (comme l'établissement de connexion TCP). Par contre, l'adresse dépréciée peut encore servir d'adresse source dans le cas des communications existantes. Les paquets reçus à une adresse dépréciée continuent à être remis normalement. Le contrôle de la durée de chaque état d'une adresse valide est effectué en ajoutant une durée de vie à l'état préféré. La figure États successifs d'une adresse sur une interface représente les différents états que prend une adresse lorsqu'elle est allouée à une interface.

Création de l'adresse lien-local

Création de l'adresse lien-local
Figure : Création de l'adresse lien-local À l'initialisation de son interface, la machine construit un identifiant pour l'interface qui doit être unique au lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse IPv6 est d'associer un préfixe à l'identifiant. L'adresse lien-local est créée en prenant le préfixe lien-local (FE80::/64) qui est fixé. L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire car la machine doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée. Si la machine détermine l'adresse lien-local n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.

Une fois que l'assurance sur l'unicité de l'adresse lien-local est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. La première phase de l'auto-configuration est achevée.

Détection d'adresse dupliquée

Emission d'un NS lors d'un DAD
Figure : Emission d'un NS lors d'un DAD Pour vérifier l'unicité des adresses lien-local ou unicast, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. L'algorithme utilise les messages ICMPv6 sollicitation d'un voisin et annonce d'un voisin. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. L'algorithme DAD consiste à envoyer un message sollicitation d'un voisin avec dans le champ adresse de la cible l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

  • Un message annonce d'un voisin est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
  • Un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD; l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
  • Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

Auto-configuration sans état

Emission d'un RS
Figure : Emission d'un RS


L'auto-configuration sans état (RFC 2462) ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s'applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l'auto-configuration sans état est qu'une machine génère son adresse IPv6 à partir d'informations locales et d'informations fournies par un routeur. Le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe.



Réception d'un RA
Figure : Réception d'un RA


Comme pour la création de l'adresse lien-local, l'adresse unicast globale est obtenue en concaténant le préfixe avec l'identifiant de l'interface. Le préfixe provient du message d'annonce de routeurs et plus précisément de l'option «information sur le préfixe». Bien qu'il faille vérifier l'unicité de toutes les adresses unicast, dans le cas d'une adresse unicast obtenue par auto-configuration sans état cela n'est pas obligatoire. En effet, l'unicité de l'identifiant de l'interface a déjà été contrôlé dans l'étape de création de l'adresse lien-local. L'identifiant étant le même, il n'y a plus aucune ambiguïté sur son unicité. L'adresse unicast globale constituée est aussi unique que celle lien-local.

La renumérotation des machines d'un lien s'effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent en même temps le nouveau préfixe. Les machines pourront recréer une adresse préférée.


Cas des réseaux NBMA

Off Link NDP: première étape
Figure : Off Link NDP: première étape

Les réseaux NBMA (Non Broadcast Multiple Access) ne donnent pas la possibilité de diffusion de tous vers tous, ce qui conduit à deux comportements possibles :

  • absence totale de diffusion, comme dans les réseaux publics (téléphonique, ATM,...) où un seul correspondant peut être joint à la fois ;
  • possibilité de diffusion par un nombre restreint d'équipements, comme par exemple les réseaux radio de type 3G, WiMAX où la station de base a la possibilité de diffuser des données vers tous les équipements tandis que l'inverse n'est pas possible.

Off Link NDP: Deuxième étape
Figure : Off Link NDP: Deuxième étape

Le comportement en réseau NBMA peut également servir à réduire les contraintes énergétiques. En effet, par exemple dans le cas des réseaux de capteurs, le multicast/broadcast est couteux en énergie puisque tous les équipements vont devoir traiter le message et certains devront le retransmettre.

Off Link NDP: Troisième étape
Figure : Off Link NDP: Troisième étape

Pour ces cas de figure, le protocole de découverte de voisins possède un mode NBMA appelé également OffLink qui n'autorise le dialogue qu'avec un routeur. Les échanges commencent de la même manière :

  • l'équipement qui souhaite s'insérer dans le réseau, émet en utilisant l'adresse de destination FF02::2 (tous les routeurs du lien), un message RS (Router Sollicitation). Le réseau NBMA devant envoyer ce message vers un routeur.
  • Le routeur répond en positionnant le bit L (OffLink) à 1 dans l'option Information sur le préfixe, indiquant que tous les échanges devront passer par lui.
  • L'équipement construit son adresse globale en concaténant le préfixe à son identifiant d'interface.
  • L'équipement envoie systématiquement tous les paquets à l'adresse physique du routeur et celui-ci qui a une vision globale du réseau les réémet vers le bon destinataire.

Off Link NDP: Quatrième étape (optionnelle)
Figure : Off Link NDP: Quatrième étape (optionnelle)

  • Si la technologie du lien le permet et si la politique de gestion du réseau l'autorise, le routeur a la possibilité d'optimiser le trafic en information l'équipement de la véritable adresse du destinataire. Le routeur émet un message d'indication de redirection (ICMP Redirect) pour informer l'équipement de l'adresse physique du destinataire. Les paquets suivants ne transiteront plus par le routeur central.

Cas des réseaux Mobiles

La duplication d'adresses est un processus relativement long puisqu'un équipement qui souhaite garantir l'unicité de son adresses doit être un message NS et attendre une absence de réponse. De plus, comme le réseau peut perdre les messages NS, un équipement peut tenter plusieurs fois de résoudre sa propre adresse avant de la garantir unique. Finalement, le processus se répète pour l'adresse lien-local et l'adresse globale. Il faut donc plusieurs secondes avant qu'un équipement puisse envoyer des paquets sur le réseau. En situation de mobilité, ce délai qui s'ajoute à ceux de la découverte des réseaux disponibles et à l'authentification, peut conduire à des ruptures de connectivité (par exemple pour la voix sur IP).

Le RFC 4429 rend plus tolérant la détection d'adresse dupliquée en autorisant un site à utiliser son adresse bien qu'elle n'ait pas été encore garantie unique. Ce comportement est appelé DAD optimiste (optimistic DAD). L'état tentative de l'adresse (voir Cycle de vie d'une adresse est remplacé par l'état optimiste pendant lequel l'unicité de l'adresse n'est pas garanti mais qui permet son utilisation. En parallèle, un DAD classique est lancé. les messages NS sont émis avec le bit O (Override) à 0 pour que les caches ND ne soit pas mis à jour au cas où cette adresse existerait déjà sur le réseau.

Découverte du MTU

Découverte du MTU première phase : envoi d'un paquet trop grand
Figure : Découverte du MTU première phase : envoi d'un paquet trop grand

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin).


Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché. S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand», en y indiquant le MTU accepté. Fort de ces informations, l'équipement émetteur réduit le PMTU supposé pour ce chemin.

Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple). Découverte du MTU seconde phase: reception d'un message ICMPv6
Figure : Découverte du MTU seconde phase: reception d'un message ICMPv6

Si la détermination du PMTU se fait essentiellement lors des premiers échanges entre les équipements concernés, elle peut également être revue en cours de transfert si, suite à un changement de route, un lien plus contraignant est traversé.

L'émetteur vérifie aussi que le PMTU n'a pas augmenté en envoyant de temps en temps un paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est augmentée.

Signalons enfin que l'algorithme de découverte du PMTU fonctionne indifféremment avec des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU minimal autorisé par l'ensemble des chemins vers chaque site destinataire du groupe de diffusion.


L'exploitation de l'information de PMTU se fait de plusieurs façons suivant l'endroit où les données à transmettre sont segmentées :

  • si un protocole de type TCP est utilisé, celui-ci assurera la segmentation de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6.
  • si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci
    • (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et
    • (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir fragmentation).

Découverte du MTU troisième phase: Emission d'un paquet de taille correcte
Figure : Découverte du MTU troisième phase: Emission d'un paquet de taille correcte Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à la discrétion de l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir routage).

Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets.

Début du chapitre Table des matières DHCPv6
Retrieved from "http://livre.g6.asso.fr/index.php?title=Protocole_de_Découverte_des_voisins&oldid=20380"
Personal tools