Difference between revisions of "IPv6 QO"

From Livre IPv6

(→‎Options dans les extentions)
(→‎Extensions)
 
(35 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
=Extentions=
+
{{Suivi|Pseudo-en-tête|Pseudo-en-tête|IPv6 Ref|Références}}
  
−
==Traitement optimisé des extentions==
+
 
 +
=Extensions=
 +
 
 +
==Traitement optimisé des extensions==
 
   
 
   
 
<tikz title="Traitement de l'option LSR en IPv4" scale="75%">
 
<tikz title="Traitement de l'option LSR en IPv4" scale="75%">
Line 56: Line 59:
 
</tikz>
 
</tikz>
  
−
<tikz title="Traitement avec l'extention de routage IPv6" scale="75%">
+
<tikz title="Traitement avec l'extension de routage IPv6" scale="75%">
 
\clip (0, 0) rectangle (10,7);
 
\clip (0, 0) rectangle (10,7);
  
Line 112: Line 115:
 
<br/>
 
<br/>
  
−
L'exemple suivant permet de souligner les problèmes d'utilisation des options dans IPv4 et la meilleure mise en œuvre des extentions d'IPv6.
+
L'exemple suivant permet de souligner les problèmes d'utilisation des options dans IPv4 et la meilleure mise en œuvre des extensions d'IPv6.
  
 
La solution (cf. figure Traitement de l'option LSR en IPv4) consiste à émettre le paquet avec l'option de routage libéral par la source (''loose source routing''). Le paquet est destiné au routeur R1, qui permute l'adresse de destination avec celle contenue dans le champ option. Le paquet franchissant les routeurs entre A et R1 puis R1 et B sera retardé à cause de la présence du champ option. Avec IPv4, les options sont obligatoirement prises en compte par tous les routeurs intermédiaires. Ceux-ci, pour des raisons de performance, privilégient les paquets sans option. De plus, par construction, la longueur du champ option est limitée à 40 octets, ce qui limite l'emploi simultané de plusieurs options.
 
La solution (cf. figure Traitement de l'option LSR en IPv4) consiste à émettre le paquet avec l'option de routage libéral par la source (''loose source routing''). Le paquet est destiné au routeur R1, qui permute l'adresse de destination avec celle contenue dans le champ option. Le paquet franchissant les routeurs entre A et R1 puis R1 et B sera retardé à cause de la présence du champ option. Avec IPv4, les options sont obligatoirement prises en compte par tous les routeurs intermédiaires. Ceux-ci, pour des raisons de performance, privilégient les paquets sans option. De plus, par construction, la longueur du champ option est limitée à 40 octets, ce qui limite l'emploi simultané de plusieurs options.
  
−
Avec IPv6 la philosophie est différente comme le montre la figure "Traitement avec l'extention de routage IPv6". Un paquet normal à destination de R1 est envoyé dans le réseau et est traité normalement par les routeurs intermédiaires. R1 reconnait son adresse et le passe à la couche supérieur qui traite l'extention de routage. Cette couche inverse les adresses et réémet le paquet vers la nouvelle destination.
+
Avec IPv6 la philosophie est différente comme le montre la figure "Traitement avec l'extension de routage IPv6". Un paquet normal à destination de R1 est envoyé dans le réseau et est traité normalement par les routeurs intermédiaires. R1 reconnait son adresse et le passe à la couche supérieur qui traite l'extension de routage. Cette couche inverse les adresses et réémet le paquet vers la nouvelle destination.
  
 
<br/>
 
<br/>
−
Cet exemple est purement théorique, en effet l'extention de routage possède plusieurs types d'extention de routage. Le type 0 (appelé également RH0 Routing Header type 0) présenté ci-dessus a été déprécié par l'IETF (RFC 5095), car il présente un risque de saturation de certains liens. En effet, si un attaquant remplit une extention de routage avec les adresses des routeurs R1, R2, R1, R2,... le paquet circulera un grand nombre de fois sur la liaison entre ces deux routeurs. L'IETF étudie la possibilité d'un autre type où le nombre d'adresses de routeurs serait limité.
+
Cet exemple est purement théorique, en effet l'extension de routage possède plusieurs types d'extension de routage. Le type 0 (appelé également RH0 Routing Header type 0) présenté ci-dessus a été déprécié par l'IETF (RFC 5095), car il présente un risque de saturation de certains liens. En effet, si un attaquant remplit une extension de routage avec les adresses des routeurs R1, R2, R1, R2,... le paquet circulera un grand nombre de fois sur la liaison entre ces deux routeurs. L'IETF étudie la possibilité d'un autre type où le nombre d'adresses de routeurs serait limité.
  
−
== Ordre des extentions==
+
== Ordre des extensions==
  
−
<tikz title="Importance de l'ordre des extentions" scale="75%">
+
<tikz title="Importance de l'ordre des extensions" scale="75%">
 
\clip (0, 0) rectangle (11,7);
 
\clip (0, 0) rectangle (11,7);
  
Line 178: Line 181:
 
*Destination (traité uniquement par l'équipement terminal)
 
*Destination (traité uniquement par l'équipement terminal)
  
−
En fait, il y a actuellement très peu de chance de trouver des extentions dans les paquets IPv6, encore moins plusieurs extentions enchaînées. Par ontre l'exemple précédent est instructif car il montre que la place d'une extention dans la chaîne est importante.  
+
En fait, il y a actuellement très peu de chance de trouver des extensions dans les paquets IPv6, encore moins plusieurs extensions enchaînées. Par ontre l'exemple précédent est instructif car il montre que la place d'une extension dans la chaîne est importante.  
  
−
On peut remarquer que ce paquet contient deux extentions destination. La première étant placée avant l'extention de routage serait traitée par tous les routeurs intermédiaire listés dans l'option de routage. La second située après, ne serait traitée que par le destinataire final. De plus cette option étant également placée après l'extention de chiffrement, ses données ne circuleraient pas en clair sur le réseau.
+
On peut remarquer que ce paquet contient deux extensions destination. La première étant placée avant l'extension de routage serait traitée par tous les routeurs intermédiaire listés dans l'option de routage. La second située après, ne serait traitée que par le destinataire final. De plus cette option étant également placée après l'extension de chiffrement, ses données ne circuleraient pas en clair sur le réseau.
  
−
De même l'extention fragmentation est située après celle de routage. Seul le destinataire final fera le réassemblage du paquet.
+
De même l'extension fragmentation est située après celle de routage. Seul le destinataire final fera le réassemblage du paquet.
  
−
==Options dans les extentions==
+
==Options dans les extensions==
  
−
<tikz title="Format générique des extentions" scale="30%">
+
<tikz title="Format générique des extensions" scale="30%">
  
 
\clip (0, 0) rectangle (11,6.5);
 
\clip (0, 0) rectangle (11,6.5);
Line 207: Line 210:
 
</tikz>
 
</tikz>
  
−
Toutes les extentions sont construites suivant le même modèle. L'extention commence par un champ Next Hop qui indique quel sera la nature de l'encapsulation suivante, comme l'indique le tableau des valeurs du champ en-tête suivant:
+
Toutes les extensions sont construites suivant le même modèle. L'extension commence par un champ Next Hop qui indique quel sera la nature de l'encapsulation suivante, comme l'indique le tableau des valeurs du champ en-tête suivant:
  
 
{{Valeurs du champ en-tête suivant}}
 
{{Valeurs du champ en-tête suivant}}
  
−
Le deuxième champ contient la longueur de l'extention, généralement en mot de 64 bits. Pour l'extention de fragmentation qui a une longueur fixe, la valeur est 0.
+
Le deuxième champ contient la longueur de l'extension, généralement en mot de 64 bits. Pour l'extension de fragmentation qui a une longueur fixe, la valeur est 0.
  
−
La partie données peut être structurée en options (comme les extentions de proche-en-proche ou de destination) ou avoir un format spécifique.  
+
La partie données peut être structurée en options (comme les extensions de proche-en-proche ou de destination) ou avoir un format spécifique.  
  
 
=== <div id=PeP> Proche-en-proche </div> ===
 
=== <div id=PeP> Proche-en-proche </div> ===
Line 228: Line 231:
 
Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).
 
Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).
  
−
[[image:Fig4-7.png|thumb|right|350px|Figure 4-7 ''Format des options IPv6'']]
+
<tikz title="Format des options IPv6">
 +
 +
\clip (0, 0) rectangle (11,6.5);
 +
% \draw[help lines] (0,0) grid (10,6);
 +
 +
\draw (2, 5.75) node (Pad0) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (Pad0.text) node {\texttt{0}};
 +
\draw (0, 5.75) node [right] {\tiny{Pad0}};
 +
 
 +
\draw (2, 5) node (Padn) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (Padn.text) node {\texttt{1}};
 +
\draw (Padn.east) node (pnlg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (pnlg.east) node (padpad) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=5cm] {};
 +
\foreach \i in {north, south} {
 +
\draw [draw=white] ([xshift=-1cm] padpad.\i) -- ([xshift=1cm] padpad.\i) ;
 +
\draw [dotted] ([xshift=-1cm] padpad.\i) -- ([xshift=1cm] padpad.\i) ;
 +
}
 +
\draw (pnlg.text) node {\small{lgth.}};
 +
\draw (padpad.text) node {\small{$0\cdots0$}};
 +
\draw (0, 5) node [right] {\tiny{Padn}};
 +
 +
\draw (2, 4.25) node (RA) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (RA.text) node {\texttt{5}};
 +
\draw (RA.east) node (ralg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (ralg.text) node {\texttt{2}};
 +
\draw (ralg.east) node (value) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=2.4cm] {};
 +
\draw (value.text) node {\small{Value}};
 +
\draw (0, 4.25) node [right] {\tiny{Router Alert}};
 +
 
 +
\draw (2, 3.5) node (Cal) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (Cal.text) node {\texttt{7}};
 +
\draw (Cal.east) node (callg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (callg.text) node {\small{lgth.}};
 +
\draw (callg.east) node (data1) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=5cm] {};
 +
\foreach \i in {north, south} {
 +
\draw [draw=white] ([xshift=-1cm] data1.\i) -- ([xshift=1cm] data1.\i) ;
 +
\draw [dotted] ([xshift=-1cm] data1.\i) -- ([xshift=1cm] data1.\i) ;
 +
}
 +
\draw (data1.text) node {\small{See RFC 5570}};
 +
\draw (0, 3.5) node [right] {\tiny{CALIPSO}};
 +
 
 +
\draw (2, 2.75) node (QS) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (QS.text) node {\texttt{38}};
 +
\draw (QS.east) node (qslg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (qslg.text) node {\small{lgth.}};
 +
\draw (qslg.east) node (data2) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=5cm] {};
 +
\foreach \i in {north, south} {
 +
\draw [draw=white] ([xshift=-1cm] data2.\i) -- ([xshift=1cm] data2.\i) ;
 +
\draw [dotted] ([xshift=-1cm] data2.\i) -- ([xshift=1cm] data2.\i) ;
 +
}
 +
\draw (data2.text) node {\small{See RFC 4782}};
 +
\draw (0, 2.75) node [right] {\tiny{Quick Start}};
 +
 +
\draw (2, 2) node (JB) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (JB.text) node {\texttt{194}};
 +
\draw (JB.east) node (jblg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (jblg.text) node {\texttt{4}};
 +
\draw (jblg.east) node (value2) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=4.8cm] {};
 +
\draw (value2.text) node {\small{Datagram Length}};
 +
\draw (0, 2) node [right] {\tiny{Jumbogram}};
 +
 
 +
 +
 
 +
</tikz>
 
   
 
   
 
Les quatre options de proche-en-proche sont :
 
Les quatre options de proche-en-proche sont :
Line 236: Line 302:
  
 
Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.
 
Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.
 +
 +
*L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (''Multicast Listener Discovery'') ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données. <br>L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux. <br> Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
 +
**0 : pour les messages du protocole MLD de gestion des groupes multicast [RFC2710];
 +
**1 : pour les messages RSVP [RFC 2711];
 +
**2 : pour les réseaux actifs [RFC 2711];
 +
** 4 à 35 : niveau d'imbrication de réservation pour RSVP [RFC 3175];
 +
** 36 à 67 : niveau d'imbrication de réservation pour NSIS [draft-ietf-nsis-qos-nslp-18.txt]
 +
 +
* L'option CALIPSO permet de donner un degré de confidentialité au paquet transporté. Elle est décrite dans le \rfc{5570}, mais doit être limité a un intranet, car l'utilisation de l'extension Hop-By-Hop nuit a l'efficacité du relayage des paquets.
 +
 +
 +
* L'option Demarrage Rapide (''Quick Start'') de manière expérimentale par le RFC 4782. Elle permet aux applications de collaborer avec les routeurs pour déterminer le débit auquel l'application peut commencer à émettre.
  
 
*Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. <br> Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.
 
*Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. <br> Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.
  
−
*L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (''Multicast Listener Discovery'') ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données. <br>L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux. <br> Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
+
 
−
**0 : pour les messages du protocole MLD de gestion des groupes multicast ;
+
−
**1 : pour les messages RSVP ;
+
−
**2 : pour les réseaux actifs ;
+
 
:les autres valeurs sont réservées.
 
:les autres valeurs sont réservées.
  
 
=== <div id=dest>Destination </div>===
 
=== <div id=dest>Destination </div>===
  
−
{{ToDo|Liste Shim6}}
+
<tikz title="Destination options">
 +
\clip (0, 2.5) rectangle (11,6.5);
 +
% \draw[help lines] (0,0) grid (10,6);
 +
 +
\draw (3, 5.75) node (TEL) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (TEL.text) node {\texttt{4}};
 +
\draw (TEL.east) node (tellg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (tellg) node {\texttt{1}};
 +
\draw (tellg.east) node (telval) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (telval.text) node {\small{Limit}};
 +
\draw (0, 5.75) node [right] {\tiny{Tun. Encap. Limit}};
 +
 +
\draw (5.4, 5) node (Mob) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (Mob.text) node {\texttt{201}};
 +
\draw (Mob.east) node (moblg) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=0.5cm, minimum width=1.2cm] {};
 +
\draw (moblg) node {\texttt{16}};
 +
\draw (3, 3.75) node (mobaddr) [right,  shade,  top color=blue!50,  bottom color=black!30, draw, minimum height=2cm, minimum width=4.8cm] {};
 +
\draw (mobaddr) node {Home Address};
 +
 +
\draw (0, 5) node [right] {\tiny{Home Address (MIP)}};
 +
 +
 
 +
</tikz>
 +
 
 +
Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Le RFC 2460 définissant IPv6 ne définit que les options de bourrage Pad1 et Padn. Les autres options sont définies dans d'autres RFC ou encore expérimentales. Les valeurs:
  
−
Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Pour l'instant, à part les options de bourrage (voir [[#Pad1|Pad1]] et [[#Padn|Padn]]) et de mobilité (cf. [[Mobilité dans IPv6]]), la seule autre option concerne le tunnelage dans des paquets IPv6 (RFC 2473). Cette option permet de limiter le niveau d'encapsulation dans des tunnels des paquets IPv6.
+
* 4 :  ''Tunnel Encapsulation Limit'' [RFC 2473]: Contient le nombre de fois maximum qu'un paquet peut être encapsulé dans les tunnels. La valeur est décrémentée a chaque fois qu'un nouveau tunnel est ajouté. Si la valeur atteint 0, le paquet est détruit et un message ICMPv6 est émis.
 +
* 201 (0xC9): contient l'adresse sur le réseau mère (''Home Address'') [RFC 3775] utilisée pour l'optimisation de la mobilité. L'en-tête IPv6 contient dans le champ adresse de la source,  l'adresse sur le réseau visité (''Care-of Address''). Cette option est utilisée pour éviter qu'un opérateur ne rejette un paquet dont l'adresse de la source ne correspond pas à la plage de valeur qu'il a attribué au site. Le récepteur remplace l'adresse de la source de l'en-tête IPv6 par celle contenue dans cette option.
  
 
=== <div id="routage">Routage ===
 
=== <div id="routage">Routage ===
−
{{HorsTexte|Utilisation de l'extention de routage en Mobilité|La mobilité IP permet à un equipement qui passe d'un réseau à un autre de maintenir overte ses session TCP. Le passage d'un réseau à un autre implique un chengement d'adresse, or TCP identifie les connexions avec les adresses d'origine. Cet extention permet à un correspondant de joindre le nœud mobile. Il envoie un paquet à sa nouvelle adresse en mettant l'adresse permanente dans l'extention de routage (type 2). La couche IP passe le paquet à la couche de traitement de l'extention qui inverse les adresses et le passe à la couche supérieure (TCP). TCP ne voyant que l'adresse permanente n'est pas informé de la mobilité de la machine.}}  
+
{{HorsTexte|Utilisation de l'extension de routage en Mobilité|La mobilité IP permet à un equipement qui passe d'un réseau à un autre de maintenir overte ses session TCP. Le passage d'un réseau à un autre implique un chengement d'adresse, or TCP identifie les connexions avec les adresses d'origine. Cet extension permet à un correspondant de joindre le nœud mobile. Il envoie un paquet à sa nouvelle adresse en mettant l'adresse permanente dans l'extension de routage (type 2). La couche IP passe le paquet à la couche de traitement de l'extension qui inverse les adresses et le passe à la couche supérieure (TCP). TCP ne voyant que l'adresse permanente n'est pas informé de la mobilité de la machine.}}  
  
 
Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau.  La [[Mobilité dans IPv6|mobilité IPv6]] a également introduit une extension de routage (type = 2) (cf. [[La gestion de la mobilité IPv6#Optimisation dans le cas du mobile dans un réseau étranger|Optimisation dans le cas du mobile dans un réseau étranger]]).
 
Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau.  La [[Mobilité dans IPv6|mobilité IPv6]] a également introduit une extension de routage (type = 2) (cf. [[La gestion de la mobilité IPv6#Optimisation dans le cas du mobile dans un réseau étranger|Optimisation dans le cas du mobile dans un réseau étranger]]).
Line 258: Line 358:
 
Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (''loose'') (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul la spécification d'un changement d'adresse au dernier lien est spéficié. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. Le routage par la source libéral pouvait conduire à une duplication de paquets dans le réseau et a été supprimé dans les dernière spécifications. Cette amplification du trafic permettant de réaliser des attaques par déni de service. Ainsi si dans la liste des routeurs a traverser, on met une liste R1, R2, R1, R2, .... le paquet fera du ping pong entre ces deux routeurs, comme l'explique le RFC 5095.
 
Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (''loose'') (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul la spécification d'un changement d'adresse au dernier lien est spéficié. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. Le routage par la source libéral pouvait conduire à une duplication de paquets dans le réseau et a été supprimé dans les dernière spécifications. Cette amplification du trafic permettant de réaliser des attaques par déni de service. Ainsi si dans la liste des routeurs a traverser, on met une liste R1, R2, R1, R2, .... le paquet fera du ping pong entre ces deux routeurs, comme l'explique le RFC 5095.
  
 +
Le seul format de routage existant est le type 2 (appelé RH2, pour Routing Header type 2) comme le montre la figure "Format de l'extension routage". Il sert pour la mobilité. Son rôle est inverse de l'option ''Home Address'' de l'extension Destination. Quand un paquet est émis vers un nœud mobile, l'adresse dans le paquet IPv6 contient l'adresse du réseau visité, et l'adresse permanente est stockée dans l'extension RH2. Le nœud mobile reçoit le paquet IPv6, traite l'extension et par conséquent remplace l'adresse de destination par la ''Home Address''. Le paquet est ensuite transmis au niveau 4 qui n'a pas la notion des changements d'adresses du nœud.
  
−
 
+
<tikz title="Format de l'extension routage">
−
[[image:Fig4-8.png|thumb|right|350px|Figure 4-8 ''Format de l'extension routage par la source'']]
+
\clip (0, 2) rectangle (11,6.5);
 +
% \draw[help lines] (0,0) grid (10,6);
 +
 +
 +
\draw (0.5, 5.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
 +
\draw (0.5, 5) node (NH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Next Header}};
 +
\draw (NH.east) node (Length) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Ext. Length=2}};
 +
\draw (Length.east) node (RH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Routing Type=2}};
 +
\draw (RH.east) node (RH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Seg. Left=1}};
 +
\draw (0.5, 4.5) node (NH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=9.63cm] {\tiny{Reserved}};
 +
 +
\draw (0.5, 3.25) node (FF) [right,  shade,  top color=blue!50,  draw, minimum height=2cm, minimum width=9.63cm] {\tiny{Home Address}};
 +
</tikz>
  
  
−
La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :
+
La figure "Format de l'extension routage" donne le format de l'extension de routage par la source :
 
   
 
   
−
*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
+
*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. Dans l'en-tête du type 2, il est fixé à 2 car une seule adresse est possible.  
−
*Le champ type indique la nature du routage. Le routage par la source, de type 0 est spécifié a été déprécié (cf RFC 5095). La suite de l'en-tête correspond à ce type.
+
*Le champ type indique la nature du routage.
−
*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.
+
** Le routage par la source, de type 0 est spécifié a été déprécié (cf RFC 5095) pour les possibilité amplification du trafic expliqué précédemment. Dans la description initiale, le champ longueur pouvait contenir un nombre quelconque d'adresses de routeurs intermédiaire. Le draft-manral-ipv6-rh4-00.txt aujourd'hui expiré proposait de borner le nombre d'adresses à 4.
−
*Les 32 bits suivants sont inutilisés pour préserver l'alignement.
+
** Le type 1 correspond à un adressage expérimental (Nimrod) testé au début d'IPv6, il est également abandonné.
−
 
+
** Le type 2 correspond à la mobilité, décrit ci dessus.  
−
La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.
+
*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. Pour RH2, il est forcement à 1.
−
 
+
*Les 32 bits suivants sont inutilisés pour préserver l'alignement sur 64 bits du premier mot et avoir ainsi la suite des adresses IPv6 sur ces mêmes frontières.
−
L'extention de mobilité définie dans le RFC 3775 diffère de la précedente par son type (2), le nombre de segment est forcé à 1 et une seule adresse contenant l'adresse sur le réseau mère.
+
  
 
=== <div id="frag">Fragmentation </div>===
 
=== <div id="frag">Fragmentation </div>===
Line 282: Line 396:
 
Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.
 
Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.
  
−
[[image:Fig4-9.png|thumb|right|350px|Figure 4-9 ''Format de l'extension de fragmentation'']]
+
<tikz title="Format de l'extension de fragmentation">
 +
\clip (0, 3.5) rectangle (11,6.5);
 +
% \draw[help lines] (0,0) grid (10,6);
 +
 +
 +
\draw (0.5, 5.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
 +
\draw (0.5, 5) node (NH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Next Header}};
 +
\draw (NH.east) node (Length) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=2.4cm] {\tiny{Ext. Length=2}};
 +
\draw (Length.east) node (Off) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=3.95cm] {\tiny{Offset}};
 +
\draw (Off.east) node (B1) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=.2cm] {}; \draw (B1.text) node {\tiny{0}};
 +
\draw (B1.east) node (B2) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=.2cm] {}; \draw (B2.text) node {\tiny{0}};
 +
\draw (B2.east) node (B3) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=.2cm] {}; \draw (B3.text) node {\tiny{M}};
 +
 
 +
\draw (0.5, 4.5) node (NH) [right, shade,  top color=blue!50,  draw, minimum height=0.5cm, minimum width=9.63cm] {\tiny{Identification}};
 +
 +
 
 +
</tikz>
 +
 
  
 
Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :
 
Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :
Line 294: Line 427:
  
 
=== Sécurité ===
 
=== Sécurité ===
−
Deux extensions de sécurité -- les extensions d'authentification AH (''Authentication Header'') et de confidentialité ESP (''Encapsulating Security Payload'') -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite [[Sécurité]], RFC 2402 donne une description détaillée de ces extensions, et présente les modes de protection existants.
+
Deux extensions de sécurité -- les extensions d'authentification AH (''Authentication Header'') et de confidentialité ESP (''Encapsulating Security Payload'') -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite [[Sécurité]], RFC 4302 donne une description détaillée de ces extensions, et présente les modes de protection existants.
−
 
+
{{Suivi|Pseudo-en-tête|Pseudo-en-tête|IPv6 Ref|Références}}
−
{{ToDo|Firewall et extentions}}
+
−
 
+
−
=Flow Label=
+

Latest revision as of 07:44, 24 June 2015

Pseudo-en-tête Table des matières Références


Extensions

Traitement optimisé des extensions

Traitement de l'option LSR en IPv4
Figure : Traitement de l'option LSR en IPv4

Traitement avec l'extension de routage IPv6
Figure : Traitement avec l'extension de routage IPv6


L'exemple suivant permet de souligner les problèmes d'utilisation des options dans IPv4 et la meilleure mise en œuvre des extensions d'IPv6.

La solution (cf. figure Traitement de l'option LSR en IPv4) consiste à émettre le paquet avec l'option de routage libéral par la source (loose source routing). Le paquet est destiné au routeur R1, qui permute l'adresse de destination avec celle contenue dans le champ option. Le paquet franchissant les routeurs entre A et R1 puis R1 et B sera retardé à cause de la présence du champ option. Avec IPv4, les options sont obligatoirement prises en compte par tous les routeurs intermédiaires. Ceux-ci, pour des raisons de performance, privilégient les paquets sans option. De plus, par construction, la longueur du champ option est limitée à 40 octets, ce qui limite l'emploi simultané de plusieurs options.

Avec IPv6 la philosophie est différente comme le montre la figure "Traitement avec l'extension de routage IPv6". Un paquet normal à destination de R1 est envoyé dans le réseau et est traité normalement par les routeurs intermédiaires. R1 reconnait son adresse et le passe à la couche supérieur qui traite l'extension de routage. Cette couche inverse les adresses et réémet le paquet vers la nouvelle destination.


Cet exemple est purement théorique, en effet l'extension de routage possède plusieurs types d'extension de routage. Le type 0 (appelé également RH0 Routing Header type 0) présenté ci-dessus a été déprécié par l'IETF (RFC 5095), car il présente un risque de saturation de certains liens. En effet, si un attaquant remplit une extension de routage avec les adresses des routeurs R1, R2, R1, R2,... le paquet circulera un grand nombre de fois sur la liaison entre ces deux routeurs. L'IETF étudie la possibilité d'un autre type où le nombre d'adresses de routeurs serait limité.

Ordre des extensions

Importance de l'ordre des extensions
Figure : Importance de l'ordre des extensions


Le RFC 2460 recommande l'ordre suivant :

  • Proche-en-proche (doit toujours être en première position)
  • Destination (sera aussi traité par les routeurs listés dans l'extension de routage par la source)
  • Routage par la source
  • Fragmentation
  • Authentification
  • Destination (traité uniquement par l'équipement terminal)

En fait, il y a actuellement très peu de chance de trouver des extensions dans les paquets IPv6, encore moins plusieurs extensions enchaînées. Par ontre l'exemple précédent est instructif car il montre que la place d'une extension dans la chaîne est importante.

On peut remarquer que ce paquet contient deux extensions destination. La première étant placée avant l'extension de routage serait traitée par tous les routeurs intermédiaire listés dans l'option de routage. La second située après, ne serait traitée que par le destinataire final. De plus cette option étant également placée après l'extension de chiffrement, ses données ne circuleraient pas en clair sur le réseau.

De même l'extension fragmentation est située après celle de routage. Seul le destinataire final fera le réassemblage du paquet.

Options dans les extensions

Format générique des extensions
Figure : Format générique des extensions

Toutes les extensions sont construites suivant le même modèle. L'extension commence par un champ Next Hop qui indique quel sera la nature de l'encapsulation suivante, comme l'indique le tableau des valeurs du champ en-tête suivant:

Valeurs du champ en-tête suivant
valeur Extension valeur Protocole
0 Proche-en-proche 4 IPv4
43 Routage 6 TCP
44 Fragmentation 17 UDP
50 Confidentialité 41 IPv6
51 Authentification 58 ICMPv6
59 Fin des en-têtes 132 SCTP
60 Destination 136 UDP-lite
135 Mobilité
140 Shim6

Le deuxième champ contient la longueur de l'extension, généralement en mot de 64 bits. Pour l'extension de fragmentation qui a une longueur fixe, la valeur est 0.

La partie données peut être structurée en options (comme les extensions de proche-en-proche ou de destination) ou avoir un format spécifique.

Proche-en-proche

Cette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.

L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :

  • 00 : le routeur ignore l'option ;
  • 01 : le routeur rejette le paquet ;
  • 10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;
  • 11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.

Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).

Format des options IPv6
Figure : Format des options IPv6

Les quatre options de proche-en-proche sont :

  • Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.
  • Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.

Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.

  • L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (Multicast Listener Discovery) ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données.
    L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux.
    Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
    • 0 : pour les messages du protocole MLD de gestion des groupes multicast [RFC2710];
    • 1 : pour les messages RSVP [RFC 2711];
    • 2 : pour les réseaux actifs [RFC 2711];
    • 4 à 35 : niveau d'imbrication de réservation pour RSVP [RFC 3175];
    • 36 à 67 : niveau d'imbrication de réservation pour NSIS [draft-ietf-nsis-qos-nslp-18.txt]
  • L'option CALIPSO permet de donner un degré de confidentialité au paquet transporté. Elle est décrite dans le \rfc{5570}, mais doit être limité a un intranet, car l'utilisation de l'extension Hop-By-Hop nuit a l'efficacité du relayage des paquets.


  • L'option Demarrage Rapide (Quick Start) de manière expérimentale par le RFC 4782. Elle permet aux applications de collaborer avec les routeurs pour déterminer le débit auquel l'application peut commencer à émettre.
  • Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0.
    Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.


les autres valeurs sont réservées.

Destination

Destination options
Figure : Destination options

Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Le RFC 2460 définissant IPv6 ne définit que les options de bourrage Pad1 et Padn. Les autres options sont définies dans d'autres RFC ou encore expérimentales. Les valeurs:

  • 4 : Tunnel Encapsulation Limit [RFC 2473]: Contient le nombre de fois maximum qu'un paquet peut être encapsulé dans les tunnels. La valeur est décrémentée a chaque fois qu'un nouveau tunnel est ajouté. Si la valeur atteint 0, le paquet est détruit et un message ICMPv6 est émis.
  • 201 (0xC9): contient l'adresse sur le réseau mère (Home Address) [RFC 3775] utilisée pour l'optimisation de la mobilité. L'en-tête IPv6 contient dans le champ adresse de la source, l'adresse sur le réseau visité (Care-of Address). Cette option est utilisée pour éviter qu'un opérateur ne rejette un paquet dont l'adresse de la source ne correspond pas à la plage de valeur qu'il a attribué au site. Le récepteur remplace l'adresse de la source de l'en-tête IPv6 par celle contenue dans cette option.

Routage

Utilisation de l'extension de routage en Mobilité

La mobilité IP permet à un equipement qui passe d'un réseau à un autre de maintenir overte ses session TCP. Le passage d'un réseau à un autre implique un chengement d'adresse, or TCP identifie les connexions avec les adresses d'origine. Cet extension permet à un correspondant de joindre le nœud mobile. Il envoie un paquet à sa nouvelle adresse en mettant l'adresse permanente dans l'extension de routage (type 2). La couche IP passe le paquet à la couche de traitement de l'extension qui inverse les adresses et le passe à la couche supérieure (TCP). TCP ne voyant que l'adresse permanente n'est pas informé de la mobilité de la machine.

Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. La mobilité IPv6 a également introduit une extension de routage (type = 2) (cf. Optimisation dans le cas du mobile dans un réseau étranger).

Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (loose) (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul la spécification d'un changement d'adresse au dernier lien est spéficié. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. Le routage par la source libéral pouvait conduire à une duplication de paquets dans le réseau et a été supprimé dans les dernière spécifications. Cette amplification du trafic permettant de réaliser des attaques par déni de service. Ainsi si dans la liste des routeurs a traverser, on met une liste R1, R2, R1, R2, .... le paquet fera du ping pong entre ces deux routeurs, comme l'explique le RFC 5095.

Le seul format de routage existant est le type 2 (appelé RH2, pour Routing Header type 2) comme le montre la figure "Format de l'extension routage". Il sert pour la mobilité. Son rôle est inverse de l'option Home Address de l'extension Destination. Quand un paquet est émis vers un nœud mobile, l'adresse dans le paquet IPv6 contient l'adresse du réseau visité, et l'adresse permanente est stockée dans l'extension RH2. Le nœud mobile reçoit le paquet IPv6, traite l'extension et par conséquent remplace l'adresse de destination par la Home Address. Le paquet est ensuite transmis au niveau 4 qui n'a pas la notion des changements d'adresses du nœud.

Format de l'extension routage
Figure : Format de l'extension routage


La figure "Format de l'extension routage" donne le format de l'extension de routage par la source :

  • Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. Dans l'en-tête du type 2, il est fixé à 2 car une seule adresse est possible.
  • Le champ type indique la nature du routage.
    • Le routage par la source, de type 0 est spécifié a été déprécié (cf RFC 5095) pour les possibilité amplification du trafic expliqué précédemment. Dans la description initiale, le champ longueur pouvait contenir un nombre quelconque d'adresses de routeurs intermédiaire. Le draft-manral-ipv6-rh4-00.txt aujourd'hui expiré proposait de borner le nombre d'adresses à 4.
    • Le type 1 correspond à un adressage expérimental (Nimrod) testé au début d'IPv6, il est également abandonné.
    • Le type 2 correspond à la mobilité, décrit ci dessus.
  • Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. Pour RH2, il est forcement à 1.
  • Les 32 bits suivants sont inutilisés pour préserver l'alignement sur 64 bits du premier mot et avoir ainsi la suite des adresses IPv6 sur ces mêmes frontières.

Fragmentation

La fragmentation telle qu'elle est pratiquée dans IPv4 n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4 quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille et si le bit DF (don't fragment) est à 0, il découpe l'information à transmettre en fragments. Or le réseau IP étant un réseau à datagramme, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et par conséquent seul le destinataire peut effectuer le réassemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir Mécanisme de découverte du PMTU (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.

Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.

Format de l'extension de fragmentation
Figure : Format de l'extension de fragmentation


Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :

  • Le champ place du fragment indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
  • Le bit M s'il vaut 1 indique qu'il y aura d'autres fragments émis.
  • Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
  • Le bit DF (don't fragment) n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.

Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.

Sécurité

Deux extensions de sécurité -- les extensions d'authentification AH (Authentication Header) et de confidentialité ESP (Encapsulating Security Payload) -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite Sécurité, RFC 4302 donne une description détaillée de ces extensions, et présente les modes de protection existants.

Pseudo-en-tête Table des matières Références
Retrieved from "http://livre.g6.asso.fr/index.php?title=IPv6_QO&oldid=7364"
Views
Personal tools
Navigation
Tools