Groupe de travail Réseau |
A. Conta, Lucent Technologies Inc. |
Request for Comments : 2473 |
S. Deering, Cisco Systems |
Catégorie : En cours de normalisation |
décembre 1998 |
Traduction Claude Brière de L'Isle |
|
Spécification du tunnelage générique de paquet dans IPv6
Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
Notice de Copyright
Copyright (C) The Internet Society (1998). Tous droits réservés.
Résumé
Le présent document définit le modèle et les mécanismes génériques de l'encapsulation IPv6 des paquets Internet, pour IPv6 et IPv4. Le modèle et les mécanismes peuvent aussi bien être appliqués aux paquets d'autres protocoles, tels que d'AppleTalk, IPX, CLNP, ou autres.
Table des Matières
3.2 Traitement des paquets dans les tunnels
3.4 Moteur du protocole de tunnel IPv6
4.1 Limitation d'encapsulation incorporée
4.1.1 Option de limite d'encapsulation de tunnel
4.1.3 Encapsulation incorporée en boucle d'acheminement
5.1 En-têtes d'extension de tunnel IPv6
6. Variables d'état de tunnel IPv6
6.1 Adresse de nœud de point d'entrée de tunnel IPv6
6.2 Adresse de nœud de point de sortie de tunnel IPv6
6.3 Limite de bond de tunnel IPv6
6.4 Classe de trafic de paquet tunnel IPv6
6.5 Étiquette de flux de tunnel IPv6
6.6 Limite d'encapsulation de tunnel IPv6
7. Questions de taille de paquet tunnel IPv6
7.1 Fragmentation de paquet tunnel IPv6
7.2 Fragmentation de paquet tunnel IPv4
8. Traitement et rapport d'erreur de tunnel IPv6
8.2 Messages ICMP pour paquets d'origine IPv6
8.3 Messages ICMP pour paquets d'origine IPv4
8.4 Messages ICMP pour paquets tunnels incorporés
9. Considérations pour la sécurité
Appendice A Facteurs de risque
A.1 Facteurs de risque dans l'encapsulation incorporée
A.1.1 Facteur de risque dans l'encapsulation incorporée - type de tunnel
A.1.2 Facteur de risque dans l'encapsulation incorporée - type de chemin.
Déclaration complète de droits de propriété intellectuelle
Le présent document spécifie une méthode et des mécanismes génériques par lesquels un paquet est encapsulé et transporté comme charge utile au sein d'un paquet IPv6. Le paquet résultant est appelé un paquet tunnel IPv6. Le chemin de transmission entre la source et la destination du paquet tunnel est appelée un tunnel IPv6. La technique est appelée tunnelage IPv6.
Un scénario typique du tunnelage IPv6 est le cas dans lequel un nœud intermédiaire exerce un contrôle explicite d'acheminement en spécifiant des chemins de transmission particuliers pour les paquets choisis. Ce contrôle est réalisé en ajoutant des en-têtes IPv6 à chacun des paquets originaux choisis. Ces en-têtes ajoutés identifient les chemins de transmission.
En plus de la description des mécanimes génériques de tunnelage IPv6, qui est le point sur lequel se concentre ce document, des mécanismes spécifiques du tunnelage des paquets IPv6 et IPv4 sont aussi décrits.
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTAIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].
paquet original
C'est un paquet qui va subir l'encapsulation.
en-tête original
C'est l'en-tête d'un paquet original.
tunnel
Chemin de transmission entre deux nœuds sur lesquels les charges utiles des paquets sont des paquets originaux.
nœud d'extrémité de tunnel
C'est un nœud où commence ou se termine un tunnel.
en-tête de tunnel
C'est l'en-tête ajouté au paquet original durant l'encapsulation. Il spécifie les points d'extrémité du tunnel comme source et destination.
paquet tunnel
C'est un paquet qui encapsule un paquet original.
point d'entrée de tunnel
C'est le nœud d'extrémité du tunnel où un paquet original est encapsulé.
point de sortie de tunnel
C'est le nœud d'extrémité de tunnel où un paquet tunnel est désencapsulé.
tunnel IPv6
C'est un tunnel configuré comme une liaison virtuelle entre deux nœuds IPv6, sur lequel le protocole d'encapsulation est IPv6.
MTU de tunnel
C'est la taille maximum de la charge utile d'un paquet tunnel sans exiger de fragmentation, c'est-à-dire la MTU du chemin entre les nœuds de point d'entrée de tunnel et de point de sortie de tunnel moins la taille de l'en-tête de tunnel.
limite de bond de tunnel
C'est le nombre maximum de bonds qu'un paquet tunnel peut parcourit depuis le point d'entrée de tunnel jusqu'au point de sortie de tunnel.
tunnel interne
C'st un tunnel qui est un bond (liaison virtuelle) d'un autre tunnel.
tunnel externe
C'est un tunnel qui contient un ou plusieurs tunnels internes.
paquet tunnel incorporé
C'est un paquet tunnel qui a un paquet tunnel comme charge utile.
en-tête de tunnel incorporé
C'est l'en-tête de tunnel d'un paquet tunnel incorporé.
encapsulation incorporée
C'est l'encapsulation d'un paquet encapsulé.
encapsulation récurrente
C'est l'encapsulation d'un paquet qui entre à nouveau dans un tunnel avant d'en sortir.
limite d'encapsulation de tunnel
C'est le nombre maximum d'encapsulations incorporées d'un paquet.
Le tunnelage IPv6 est une technique pour établir une "liaison virtuelle" entre deux nœuds IPv6 pour transmettre des paquets de données comme charges utiles de paquets IPv6 (voir la Figure 1). Du point de vue des deux nœuds, cette "liaison virtuelle", appelée un tunnel IPv6, apparaît comme une liaison point à point sur laquelle IPv6 agit comme un protocole de couche liaison. Les deux nœuds IPv6 jouent des rôles spécifiques. Un nœud encapsule les paquets originaux reçus des autres nœuds ou de lui-même et transmet les paquets tunnels résultants à travers le tunnel. L'autre nœud désencapsule les paquets tunnels reçus et transmet les paquets originaux résultants à leurs destinations, éventuellement lui-même. Le nœud encapsuleur est appelé le nœud de point d'entrée de tunnel, et il est la source des paquets tunnels. Le nœud désencapsuleur est appelé le point de sortie de tunnel, et il est la destination des paquets tunnels.
Note : Le présent document se réfère en particulier aux tunnels entre deux nœuds identifiés par des adresses d'envoi individuel – de tels tunnels ressemblent à des "liaisons virtuelles en point à point". Les mécanismes décrits ici s'appliquent aussi aux tunnels dans lesquels les nœuds de point de sortie sont identifiés par d'autres types d'adresses, telles que d'envoi à la cantonade ou de diffusion groupée. Ces tunnels peuvent ressembler à des "liaisons virtuelles en point à multipoint". Au moment de la rédaction du présent document, les adresses IPv6 d'envoi à la cantonnade sont un sujet en cours de spécification et de travaux expérimentaux.
Tunnel du nœud B au nœud C
<---------------------->
Nœud de Nœud de
point d'entrée point de sortie
du tunnel du tunnel
+-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
+-+ +-+ +-+ +-+
Nœud de source Nœud de destination
du paquet original du paquet original
Figure 1 : Tunnel
Un tunnel IPv6 est un mécanisme unidirectionnel – le flux de paquets tunnels a lieu dans une direction entre le point d'entrée de tunnel IPv6 et les nœuds de point de sortie (voir la Figure 1).
Tunnel du nœud B au nœud C
<------------------------>
Nœud source Nœud de point Nœud de point Nœud de
du paquet d'entrée de sortie destination du
original du tunnel du tunnel paquet original
+-+ +-+ +-+ +-+
| |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
|A| |B| |C| |D|
| |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
+-+ +-+ +-+ +-+
Nœud de Nœud de point Nœud de Nœud de source
destination du de sortie point d'entrée du paquet
paquet original du tunnel du tunnel original
<------------------------->
Tunnel du nœud C au nœud B
Figure 2 : Mécanisme de tunnelage bidirectionnel
Le tunnelage bidirectionnel est réalisé par la fusion de deux mécanismes unidirectionnels , c'est-à-dire, en configurant deux tunnels, chacun de direction opposée à celle de l'autre - le nœud de point d'entrée d'un tunnel est le nœud de point de sortie de l'autre tunnel (voir la Figure 2).
L'encapsulation IPv6 consiste en l'ajout au paquet original d'un en-tête IPv6 et, facultativement, d'un ensemble d'en-têtes d'extension IPv6 (voir la Figure 3) qui sont collectivement appélés en-têtes de tunnel IPv6. L'encapsulation à lieu à un nœud de point d'entrée de tunnel IPv6, car le résultat d'un paquet original est transmis sur la liaison virtuelle représentée par le tunnel. Le paquet original est traité durant la transmission conformément aux règles de transmission du protocole de ce paquet. Par exemple, si le paquet original est :
(a) un paquet IPv6, la limite de bond de l'en-tête original IPv6 est décrémentée de un ;
(b) un paquet IPv4, le champ Durée de vie (TTL) de l'en-tête original IPv4 est décrémenté de un.
À l'encapsulation, le champ Source de l'en-tête IPv6 du tunnel est rempli avec une adresse IPv6 du nœud de point d'entrée de tunnel, et le champ Destination avec une adresse IPv6 du point de sortie de tunnel. Ensuite, le paquet tunnel résultant de l'encapsulation est envoyé vers le nœud de point de sortie de tunnel.
+----------------------------------//-----+
| En-tête | |
| | Charge utile du paquet |
| original | original |
+----------------------------------//-----+
< Paquet original >
|
v
<En-têtes de tunnel > < Paquet original >
IPv6
+---------+ - - - - - +-------------------------//--------------+
| En-tête | En-têtes | |
| |d'extension| Paquet original |
| IPv6 | IPv6 | |
+---------+ - - - - - +-------------------------//--------------+
< Paquet tunnel IPv6 >
Figure 3 : Encapsulation d'un paquet
Les en-têtes d'extension de tunnel devraient apparaître dans l'ordre recommandé par la spécifications qui définit les en-têtes d'extension, comme la [RFC2460].
Une source de paquets originaux et un point d'entrée de tunnel qui encapsule ces paquets peuvent être le même nœud.
3.2 Traitement des paquets dans les tunnels
Les nœuds intermédiaires dans le tunnel traitent les paquets tunnels IPv6 conformément au protocole IPv6. Par exemple, un en-tête d'extension Options de tunnel bond par bond est traité par chaque nœud receveur dans le tunnel ; un en-tête d'extension d'acheminement de tunnel identifie les nœuds de traitement intermédiaires, et contrôle à une granularité plus fine le chemin de transmission du paquet tunnel à travers le tunnel ; un en-tête extension d'options de destination de tunnel est traité au nœud de point de sortie de tunnel.
La désencapsulation est montrée par le graphique de la Figure 4 :
+---------+- - - - - -+----------------------------------//-------+
| En-tête | En-tête | |
| |d'extension| Paquet original |
| IPv6 | IPv6 | |
+---------+- - - - - -+----------------------------------//-------+
< Paquet tunnel IPv6 >
|
v
+----------------------------------//-------+
| En-têtes | |
| | Charge utile du paquet original|
| originaux| |
+----------------------------------//-------+
< Paquet original >
Figure 4 : Désencapsulation d'un paquet
À réception d'un paquet IPv6 destiné à une adresse IPv6 d'un nœud de point de sortie de tunnel, sa couche de protocole IPv6 traite les en-têtes de tunnel. Les règles strictes de traitement de gauche à droite des en-têtes d'extension sont appliquées. Lorsque le traitement est achevé, le contrôle est passé au prochain moteur de protocole, qui est identifié par la valeur du champ Prochain en-tête dans le dernier en-tête traité. Si elle est mise à une valeur de protocole de tunnel, le moteur de protocole de tunnel élimine l'en-tête de tunnel et passe le paquet original résultant au protocole Internet ou au protocole de couche inférieure identifié par cette valeur pour le traitement ultérieur.
Par exemple, dans le cas où le champ Prochain en-tête a la valeur du protocole de tunnel IPv6, le paquet original résultant est passé à la couche de protocole IPv6.
Le nœud de point de sortie de tunnel, qui désencapsule les paquets tunnels, et le nœud de destination, qui reçoit les paquets originaux résultants peuvent être le même nœud.
3.4 Moteur du protocole de tunnel IPv6
Le graphique de la Figure 5 montre le flux de paquets (chemins n° 1 à 7) à travers le moteur de protcole de tunnel IPv6 :
Note : À la Figure 5, la boîte des protocoles de couche supérieure représente les protocoles de transport tels que TCP, UDP, les protocoles de contrôle tels que ICMP, les protocoles d'acheminement tels que OSPF, et les protocoles de couche internet ou inférieure qui sont "tunnelés" sur IPv6, comme IPv4, IPX, etc. La boîte des protocoles de couche Liaison représente Ethernet, un anneau à jetons, FDDI, PPP, X.25, le relais de trame, ATM, etc..., aussi bien que les "tunnels" de couche Internet tels que des tunnels IPv4.
Le moteur de protocole de tunnel IPv6 agit à la fois comme "couche supérieure" et comme "couche de liaison", chacune avec une entrée et une sortie spécifique, comme suit :
(u.i) "entrée de tunnel de couche supérieure" – consiste en paquets de tunnel IPv6 qui vont être désencapsulés. Les paquets tunnels entrent dans la couche IPv6 en provenance de
(u.i.1) une couche de liaison – (chemin n° 1, Figure 5)
Ces sont des paquets tunnels destinés à ce nœud et qui vont subir la désencapsulation.
(u.i.2) une couche liaison tunnel – (chemin n° 7, Figure 5)
Ce sont des paquets tunnels qui vont subir une ou plusieurs désencapsulations sur ce nœud, c'est-à-dire, les paquets ont un ou plusieurs en-têtes de tunnel incorporés et un en-tête de tunnel incorporé a été juste éliminé. Ce nœud est le point de sortie à la fois d'un tunnel externe et d'un ou plusieurs de ses tunnels internes.
Pour les deux cas ci-dessus les paquets originaux résultants sont repassés à la couche IPv6 comme résultat de "couche de liaison tunnel" pour un traitement utltérieur (voir en b.2).
+-----------------------+ +-----------------------------------+
| Protocoles de | | Couche supérieure de tunnel IPv6 |
| | | |
| couche supérieure | | ---<-------------------<------- |
| | | | ---->---|------>--------- | |
| | | | | | | | | |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | v ^ |
v ^ v ^ v ^ v ^ Paquets | | | |
| | | | | | | | tunnels | D | |
+---------------------------------------------+ | É | |
| | | | | / / | | | | S E |
| v ^ Couche | --<-3--/-/--<---- | | | | E N |
| | | IPv6 ---->-4-/-/--->-- | | | | | N C |
| v ^ / 1 | | | | | | C A |
| | | 2 / | | | | | | A P |
| v ^ -----<---5---/-/-<---- v ^ v ^ | | P S |
| | | | -->---6---/-/-->-- | | | | | | | S U |
| v ^ | | / / 6 5 4 3 8 7 | | U L |
| | | | | / / | | | | | | | | L E |
| v ^ v ^ / / v ^ | | | | | | E | |
+---------------------------------------------+ | | | |
| | | | | | | | | | | | | | | |
v ^ v ^ v ^ v ^ v ^ v ^ Paquets | | | |
| | | | | | | | | | | |originaux| v ^ |
+-----------------------+ +-----------------------+ | | |
| | || | | | | | | | |
| Protocoles | || --|---|-------<-------- | |
| de couche | | --->--------------->------>-- |
| | | |
| Liaison | | Couche Liaison de tunnel IPv6 |
+-----------------------+ +---------------------------------+
Figure 5 : Flux de paquets dans le moteur de protocole de tunnelage IPv6 sur un nœud
(u.o) "sortie de de tunnel de couche supérieure" – consiste en paquets tunnels IPv6 qui sont passés au travers de la couche IPv6 à :
(u.o.1) une couche de liaison – (chemin n° 2, Figure 5)
Ces paquets subissent l'encapsulation et sont envoyés sers le point de sortie de tunnel
(u.o.2) une couche de liaison tunnel – (chemin n° 8, Figure 5)
Ces paquets tunnels subissent l'encapsulation incorporée. Ce nœud est le nœud point d'entrée à la fois d'un tunnel externe et d'un ou plusieurs de ses tunnels internes.
Note de mise en œuvre : l'entrée et la sortie de la couche supérieure de tunnel peut être mise en œuvre de la même façon que l'entrée et la sortie des autres protocoles de couche supérieure.
L'entrée et la sortie de couche supérieure de tunnel sont comme suit :
(l.i) "entrée de couche liaison tunnel" – consiste en paquets originaux IPv6 qui vont être encapsulés.
Les paquets originaux entrent dans la couche IPv6 en provenance de :
(l.i.1) une couche supérieure – (chemin n° 4, Figure 5)
Ce sont des paquets originaux générés sur ce nœud qui subissent l'encapsulation. La source et le point d'entrée de tunnel du paquet original sont le même nœud.
(l.i.2) une couche de liaison – (chemin n° 6, Figure 5)
Ce sont des paquets originaux entrant d'un nœud différent qui subissent l'encapsulation en ce nœud de point d'entrée de tunnel.
(l.i.3) une couche supérieure tunnel – (chemin n° 8, Figure 5)
Ces paquets sont des paquets tunnels qui subissent l'encapsulation incorporée. Ce nœud est le nœud de point d'entrée à la fois d'un tunnel externe et d'un ou plusieurs de ses tunnels internes.
Les paquets tunnels résultants sont passés comme paquets de sortie de couche supérieure tunnel à travers la couche IPv6 (voir u.o) à :
(l.o) "sortie de couche liaison tunnel" – consiste en paquets IPv6 originaux résultant de désencapsulation. Ces paquets sont passés à travers la couche IPv6 à :
(l.o.1) une couche supérieure – (chemin n° 3, Figure 5)
Ces paquets originaux sont destinés à ce nœud.
(l.o.2) une couche liaison – (chemin n° 5, Figure 5)
Ces paquets originaux sont destinés à un autre nœud ; ils sont transmis sur une liaison vers leur destination.
(l.o.3) une couche supérieure tunnel – (chemin n° 7, Figure 5)
Ces paquets subissent une autre désencapsulation; ils étaient des paquets tunnels incorporés. Ce nœud est à la fois le nœud de point de sortie d'un tunnel externe et un ou plusieurs tunnels internes.
Note de mise en œuvre : L'entrée et la sortie de la couche liaison tunnel peuvent être mises en œuvre de la même façon que l'entrée et la sortie des autres protocoles de couche liaison, par exemple, en associant une interface ou pseudo-interface au tunnel IPv6.
Le choix de la "liaison tunnel IPv6" parmi d'autres liaisons résulte de la décision de transmission du paquet prise sur la base du contenu du tableau d'acheminement du nœud.
L'encapsulation IPv6 incorporée est l'encapsulation d'un paquet tunnel. Elle a lieu lorsque un bond d'un tunnel IPv6 est un tunnel. Le tunnel contenant un tunnel est appelé un tunnel externe. Le tunnel contenu dans le tunnel externe est appélé un tunnel interne – voir à la Figure 6. Les tunnels internes et leurs tunnels externes sont des tunnels incorporés.
Le nœud de point d'entrée d'un "tunnel interne IPv6" reçoit des paquets tunnels IPv6 encapsulés par le nœud de point d'entrée du "tunnel externe IPv6". Le "nœud de point d'entrée de tunnel interne" traite les paquets tunnels reçus comme des paquets originaux et effectue l'encapsulation. Les paquets résultants sont des "paquets tunnels" pour le "tunnel interne IPv6", et des "paquets tunnels incorporés" pour le "tunnel externe IPv6".
Tunnel externe
<-------------------------------------->
<--liaisons--><--liaison virtuelle-----><---liaisons--->
Tunnel interne
Nœud de point Nœud de point
d'entrée de de sortie de
tunnel externe tunnel externe
+-+ +-+ +-+ +-+ +-+ +-+
| | | | | | | | | | | |
| |-->-//-->-| |==>==//==>==| |**>**//**>**| |==>==//=>==| |-->--//-->-| |
| | | | | | | | | | | |
+-+ +-+ +-+ +-+ +-+ +-+
Nœud source Nœud de point Nœud de point Nœud de destination
du paquet d'entrée de de sortie de du paquet original
original tunnel interne tunnel interne
Figure 6 : Encapsulation incorporée
4.1 Limitation d'encapsulation incorporée
Un paquet tunnel IPv6 est limité à la taille maximum de paquet IPv6 de la [RFC2460]. Chaque encapsulation ajoute à la taille d'un paquet encapsulé la taille des en-têtes du tunnel IPv6. Par conséquent, le nombre des en-têtes de tunnel, et donc, le nombre des encapsulations incorporées, est limité par la taille maximum de paquet. Cependant, cette limite est si grande (plus de 1600 encapsulations pour un paquet original de taille minimum) qu'elle n'a pas d'effet de limite dans la plupart des cas.
L'augmentation de taille d'un paquet tunnel IPv6 du fait de l'encapsulation incorporée peut exiger la fragmentation [RFC2460] à un point d'entrée de tunnel – voir à la section 7. De plus, chaque fragmentation, due à l'encapsulation incorporée, d'un paquet tunnel déjà fragmenté, résulte en un doublement du nombre de fragments. De surcroît, il est probable qu'une fois que cette fragmentation a commencé, chaque nouvelle encapsulation incorporée résulte en encore plus de fragmentation supplémentaire. Il est donc recommandé de limiter l'encapsulation incorporée.
Le mécanisme proposé pour limiter une encapsulation incorporée excessive est une option "Limite d'encapsulation de tunnel", qui est portée dans un en-tête d'extension IPv6 Options de destination qui accompagne un en-tête d'encapsulation IPv6.
Un nœud de point d'entrée de tunnel peut être configuré de façon à inclure une option Limite d'encapsulation de tunnel au titre des informations ajoutées à tous les paquets qui entrent dans un tunnel à ce nœud. L'option Limite d'encapsulation de tunnel est portée dans un en-tête d'extension Options de destination [RFC2460] placé entre l'en-tête d'encapsulation IPv6 et l'en-tête IPv6 du paquet original. (D'autres en-têtes d'extension IPv6 peuvent aussi être présents, précédants ou suivants l'en-tête d'extension Options de destination, selon les informations de configuration au nœud de point d'entrée de tunnel.)
L'option Limite d'encapsulation de tunnel spécifie combien il est permis d'ajouter de niveaux additionnels d'encapsulation au paquet – ou, en d'autres termes, combien d'autres niveaux d'incorporation sont permis au paquet sans compter l'encapsulation dans laquelle l'option est elle-même contenue. Par exemple, une option Limite d'encapsulation de tunnel qui contient une valeur de limite de zéro signifie qu'un paquet qui porte cette option ne peut plus entrer dans un autre tunnel avant de sortir du tunnel en cours.
L'option Limite d'encapsulation de tunnel a le format suivant :
Type d'option Longueur des Valeur des données
0 1 2 3 4 5 6 7 données d'option d'option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 1 | Lim encap tunn|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type d'option, valeur décimale 4
- Les deux bits de poids forts – mis à 00 – indiquent "sauter cette option si elle n'est pas reconnue".
- Le troisième bit de poids fort – mis à 0 – indique que les données d'option dans cette option ne changent pas en route vers la destination du paquet [RFC2460].
Longueur des données d'option, valeur 1 – la portion de données de l'option est longue d'un octet.
Valeur des données d'option : c'est la valeur de la limite d'encapsulation du tunnel – un entier non signé de 8 bits qui spécifie combien d'autres niveaux d'encapsulation sont permis pour les options de limite d'encapsulation de tunnel et ne présente d'intérêt que pour les points d'entrée de tunnel. Il est exigé d'un nœud de point d'entrée de tunnel qu'il exécute la procédure suivante pour chaque paquet qui entre dans un tunnel à ce nœud :
(a) Examiner le paquet pour voir si une option Limite d'encapsulation de tunnel est présente à la suite de son en-tête IPv6. Les en-têtes qui suivent l'en-tête IPv6 doivent être examinés dans l'ordre "de gauche à droite" strict, l'examen s'arrêtant aussitôt que l'un des en-têtes suivants est rencontré : (i) un en-tête d'extension Options de destination qui contient une limite d'encapsulation de tunnel, (ii) un autre en-tête IPv6, (iii) un en-tête qui n'est pas d'extension, tel qu'un en-tête TCP, UDP, ou ICMP, ou (iv) un en-tête qui ne peut être analysé parce qu'il est chiffré ou parce que son type est inconnu. (Noter que cette exigence est une exception à la règle générale d'IPv6 qu'un en-tête d'extension Options de destination a seulement besoin d'être examiné par le nœud de destination d'un paquet. Une autre approche "plus propre" aurait été d'utiliser un en-tête d'extension bond par bond à cette fin, mais cela aurait imposé une charge indésirable de traitement supplémentaire avec pour conséquence possible un retard supplémentaire, à chaque nœud IPv6 le long du chemin d'un tunnel.)
(b) Si une option Limite d'encapsulation de tunnel se trouve dans le paquet entrant dans le tunnel et si sa valeur limite est zéro, le paquet est éliminé et un messageICMP Problème de paramètre [RFC2463] est envoyé à la source du paquet, qui est le nœud de point d'entrée de tunnel précédent. Le champ Code du message Problème de paramètre est mis à zéro ("champ d'en-tête erronné rencontré") et le champ Pointeur est réglé à pointer sur le troisième octet de l'option Limite d'encapsulation de tunnel (c'est-à-dire, l'octet contenant la valeur limite de zéro).
(c) Si une option Limite d'encapsulation de tunnel se trouve dans le paquet entrant dans le tunnel et si sa valeur limite est différente de zéro, une option Limite d'encapsulation de tunnel supplémentaire doit être incluse au titre des en-têtes d'encapsulation qui sont ajoutés à ce point d'entrée. La valeur limite dans l'option encapsulante est réglée à un de moins que la valeur limite trouvée dans le paquet en cours d'encapsulation.
(d) Si une option Limite d'encapsulation de tunnel ne se trouve pas dans le paquet qui entre dans le tunnel et si une limite d'encapsulation a été configurée pour ce tunnel, une option Limite d'encapsulation de tunnel doit être incluse au titre des en-têtes d'encapsulation ajoutés à ce point d'entrée. La valeur limite dans l'option est réglée à la limite configurée.
(e) Si une option Limite d'encapsulation de tunnel ne se trouve pas dans le paquet qui entre dans le tunnel et si aucune limite d'encapsulation n'a été configurée pour ce tunnel, aucune option Limite d'encapsulation de tunnel n'est alors incluse au titre des en-têtes d'encapsulation ajoutés à ce point d'entrée.
Une option Limite d'encapsulation de tunnel ajoutée à un nœud de point d'entrée de tunnel est retirée au titre du processus de désencapsulation à ce nœud de point de sortie de tunnel.
Deux cas d'encapsulation qui devraient être évités sont décrits ci-dessous.
Un cas particulier d'encapsulation qui doit être évité est l'encapsulation en boucle. L'encapsulation en boucle a lieu lorsque un nœud de point d'entrée de tunnel IPv6 encapsule des paquets de tunnel IPv6 générés à partir de lui-même, et destinés à lui-même. Cela peut générer une boucle de traitement infinie dans le nœud de point d'entrée.
Pour éviter une telle situation, il est recommandé qu'une mise en œuvre ait un mécanisme qui vérifie et rejette la configuration d'un tunnel dans laquelle les adresses de nœud de point de d'entrée et de sortie appartiennent toutes deux au même nœud. Il est aussi recommandé que le moteur qui encapsule vérifie et rejette l'encapsulation d'un paquet qui a la paire d'adresses de point d'entrée et de point de sortie de tunnel identique à la paire d'adresses de source d'origine et de destination finale du paquet.
Dans le cas d'un chemin de transmission avec des tunnels incorporés à plusieurs niveaux, une boucle d'acheminement d'un tunnel interne à un tunnel externe est particulièrement dangereuse lorsque les paquets provenant des tunnels internes rentrent dans un tunnel externe d'où ils ne sont pas encore sortis. Dans un tel cas, l'encapsulation incorporée devient une encapsulation récurrente avec les effets négatifs décrits en 4.1. Comme chaquc encapsulation incorporée ajoute un en-tête de tunnel avec une nouvelle valeur de limite de bond, le mécanisme IPv6 de limite de bonds ne peut pas contrôler le nombre de fois où le paquet atteint le nœud extérieur de point d'entrée de tunnel, et donc ne peut pas contrôler le nombre d'encapsulations récurrentes.
Lorsque le chemin d'un paquet de sa source à sa destination finale inclut des tunnels, le nombre maximum de bonds que le paquet peut traverser devrait être contrôlé par deux mécanismes utilisés conjointement pour éviter les effets négatifs de l'encapsulation récurrente dans des boucles d'acheminement :
(a) la limite de bonds du paquet original.
Elle est décrémentée à chaque opération de transmission effectuée sur un paquet original. Cela inclut chaque encapsulation du paquet original. Cela n'inclut pas les encapsulations incorporées du paquet original
(b) la limite d'encapsulation de paquet tunnel IPv6.
Elle est décrémentée à chaque encapsulation incorporée du paquet.
Voir en Appendice A un exposé sur les facteurs de risque d'une encapsulation excessive dans l'encapsulation incorporée.
Le nœud de point d'entrée de tunnel remplit comme suit l'en-tête principal d'un tunnel IPv6 [RFC2460] :
Version : valeur 6
Classe de trafic : Selon la configuration du nœud de point d'entrée du tunnel, la classe de trafic peut être réglée à celle du paquet original ou à une valeur préconfigurée - voir au paragraphe 6.4.
Étiquette de flux : Selon la configuration du nœud de point d'entrée du tunnel, l'étiquette de flux peut être réglée à une valeur préconfigurée. La valeur normale est zéro - voir au paragraphe 6.5.
Longueur de charge utile : C'est la longueur du paquet original, plus la longueur des en-têtes d'extension IPv6 encapsulants (ajoutés en-tête) s'il en est.
Prochain en-tête : C'est la valeur du prochain en-tête conformément à la [RFC2460] d'après les numéros alloués de la [RFC1700] ou de ses successeurs.
Par exemple, si le paquet original est un paquet IPv6, cela est réglé à :
- valeur décimale 41 (numéro alloué de Prochain en-tête pour IPv6) – si il n'y a pas d'en-tête d'extension de tunnel.
- valeur 0 (numéro alloué de Prochain en-tête pour l'en-tête d'extension Options bond par bond) – si un en-tête d'extension d'option bond par bond suit immédiatement l'en-tête de tunnel IPv6.
- valeur décimale 60 (numéro alloué de Prochain en-tête pour l'en-tête d'extension Options de destination IPv6) – si un en-tête d'extension Option de destination suit immédiatement l'en-tête de tunnel IPv6.
Limite de bonds : La limite de bonds de l'en-tête du tunnel IPv6 est réglée à une valeur préconfigurée - voir au paragraphe 6.3.
La valeur par défaut pour les hôtes est la limite de bonds annoncée dans la découverte de voisin [RFC2461]. La valeur par défaut pour les routeurs est la valeur de limite de bonds IPv6 tirée de la RFC des Numéros alloués (64 au moment de la rédaction du présent document).
Adresse de source : C'est une adresse IPv6 de l'interface sortante du nœud de point d'entrée de tunnel. Cette adresse est configurée comme adresse du nœud de point d'entrée de tunnel - voir au paragraphe 6.1.
Adresse de destination : C'est une adresse IPv6 du nœud de point de sortie du tunnel. Cette adresse est configurée comme adresse du nœud de point de sortie de tunnel - voir au paragraphe 6.2.
5.1 En-têtes d'extension de tunnel IPv6
Selon les paramètres de configuration du nœud IPv6, un nœud de point d'entrée de tunnel peut ajouter à l'en-tête principal du tunnel IPv6 un ou plusieurs en-têtes d'extension IPv6, comme un en-tête d'option Bond par bond, un en-tête Acheminement, ou d'autres.
Pour limiter le nombre d'encapsulations incorporées d'un paquet, si il était configuré pour le faire - voir au paragraphe 6.6 - un point d'entrée de tunnel inclut un en-tête d'extension Options de destination contenant une option Limite d'encapsulation de tunnel. Si cette option est la seule option présente dans l'en-tête Options de destination, l'en-tête a le format suivant :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prochain entête|Long entt ext=0|Type d'option=4|Long dns opt =1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tun Encap Lim |PadN Opt Type=1|Long dns opt =1|Donnéesd'option|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prochain en-tête :
Identifie le type de l'en-tête du paquet original. Par exemple, si le paquet original est un paquet IPv6, la valeur du prochain en-tête de protocole est réglée à la valeur 41 en décimal (numéro alloué de type de charge utile pour IPv6).
Long entt ext :
Longueur de l'en-tête d'extension Options de destination en unités de 8 octets, non inclus les huit premiers octets. Réglé à la valeur 0, si aucune autre option n'est présente dans cet en-tête d'options de destination.
Type d'option :
valeur 4 - voir au paragraphe 4.1.1.
Long dns opt (longueur des données de l'option) :
valeur 1 - voir au paragraphe 4.1.1.
Tun Encap Lim (Limite d'encapsulation de tunnel) :
entier non signé de 8 bits - voir au paragraphe 4.1.1.
PadN Opt Type (Type d'option N bits de bourrage) :
valeur 1 – option PadN, pour aligner l'en-tête à la suite de cet en-tête.
Opt Data Len (Longueur des données d'option) :
valeur 1 - un octet de données d'option.
Donnéesd'option :
valeur 0 – un octet à zéro.
6. Variables d'état de tunnel IPv6
Les variables d'état de tunnel IPv6, dont certaines sont, ou peuvent être, configurées au nœud de point d'entrée de tunnel sont décrites dans les paragraphes suivants.
6.1 Adresse de nœud de point d'entrée de tunnel IPv6
L'adresse du nœud de point d'entrée de tunnel est une des adresses IPv6 d'envoi individuel valide du nœud de point d'entrée – la validation de l'adresse au moment de la configuration du tunnel est recommandée.
L'adresse du nœud de point d'entrée du tunnel est copiée dans le champ d'adresse de source dans l'en-tête du tunnel IPv6 durant l'encapsulation du paquet.
6.2 Adresse de nœud de point de sortie de tunnel IPv6
L'adresse du nœud de point de sortie du tunnel est utilisée comme adresse de destination IPv6 pour l'en-tête du tunnel IPv6. Un tunnel agit comme liaison virtuelle en point à point entre le nœud de point d'entrée et le nœud de point de sortie.
L'adresse du nœud de point de sortie du tunnel est copiée dans le champ d'adresse de destination dans l'en-tête du tunnel IPv6 durant l'encapsulation du paquet.
La configuration des adresses du point d'entrée et de sortie du tunnel n'est pas sujette à autoconfiguration IPv6 ou à découverte de voisin IPv6.
6.3 Limite de bonds de tunnel IPv6
Un tunnel IPv6 est modélisé comme un tunnel de "liaison virtuelle à un seul bond", dans laquelle le passage du paquet original à travers le tunnel est comme le passage du paquet original sur une liaison à un seul bond, sans considération du nombre de bonds dans le tunnel IPv6.
Le mécanisme de "un seul bond" devrait être mis en œuvre en faisant que le nœud de point d'entrée du tunnel règle la limite des bonds de l'en-tête du tunnel IPv6 indépendamment de la limite des bonds de l'en-tête original.
Le mécanisme de "un seul bond" cache aux paquets IPv6 originaux le nombre de bonds du tunnel IPv6.
Il est recommandé que la limite des bonds de tunnel soit configurée avec une valeur qui assure :
(a) que les paquets tunnels IPv6 peuvent atteindre le nœud de point de sortie du tunnel,
(b) une expiration rapide du paquet tunnel si une boucle d'acheminement survient au sein du tunnel IPv6.
La valeur par défaut de limite de bonds du tunnel pour les hôtes est la limite de bonds annoncée dans la découverte de voisin IPv6 [RFC2461]. La valeur par défaut de limite de bonds du tunnel pour les routeurs est la valeur par défaut de Limite de bonds IPv6 tirée de la [RFC1700] Numéros alloués (64 au moment de la rédaction de ce document).
La limite de bonds du tunnel est copiée dans le champ Limite de bonds de l'en-tête de tunnel IPv6 de chaque paquet encapsulé par le nœud de point d'entrée de tunnel.
6.4 Classe de trafic de paquet tunnel IPv6
La classe de trafic du paquet tunnel IPv6 indique la valeur qu'un nœud de point d'entrée de tunnel établit dans le champ Classe de trafic d'un en-tête de tunnel. La valeur par défaut est zéro. La classe de trafic de paquet configurée peut aussi indiquer si la valeur du champ Classe de trafic dans l'en-tête de tunnel est copiée de l'en-tête original, ou si elle est réglée à la valeur préconfigurée.
6.5 Étiquette de flux de tunnel IPv6
L'étiquette de flux de tunnel IPv6 indique la valeur qu'un nœud de point d'entrée de tunnel établit dans l'étiquette de flux d'un en-tête de tunnel. La valeur par défaut est zéro.
6.6 Limite d'encapsulation de tunnel IPv6
La valeur de limite d'encapsulation de tunnel peut indiquer si le nœud de point d'entrée est configuré pour limiter le nombre d'encapsulations des paquets tunnels générés sur ce nœud. La limite d'encapsulation de tunnel IPv6 est le nombre maximum d'encapsulations supplémentaires permises pour les paquets qui subissent l'encapsulation à ce nœud de point d'entrée. La valeur par défaut recommandée est 4. Un nœud de point d'entrée configuré pour limiter le nombre d'encapsulations incorporées ajoute un en-tête d'extension Options de destination qui contient une option Limite d'encapsulation de tunnel à un paquet original qui subit l'encapsulation - voir aux paragraphes 4.1 et 4.1.1.
La MTU de tunnel est réglée de façon dynamique à la MTU de chemin entre les nœuds de point d'entrée de tunnel et de point de sortie de tunnel, moins la taille des en-têtes de tunnel : la taille maximum de la charge utile d'un paquet tunnel peut être envoyée à travers le tunnel sans fragmentation [RFC2460]. Le nœud de point d'entrée de tunnel effectue la découverte de la MTU du chemin sur le chemin entre les nœuds de point d'entrée et de sortie de tunnel [RFC1981], [RFC2463]. La MTU de tunnel d'un tunnel incorporé est la MTU de tunnel du tunnel externe moins la taille de l'en-tête de tunnel incorporé.
7. Questions de taille de paquet tunnel IPv6
L'ajout d'un en-tête de tunnel augmente la talle d'un paquet, donc un paquet tunnel résultant de l'encapsulation d'un paquet IPv6 original peut exiger une fragmentation.
Un paquet tunnel IPv6 résultant de l'encapsulation d'un paquet original est considéré comme un paquet IPv6 originaire du nœud de point d'entrée du tunnel. Donc, comme toute source d'un paquet IPv6, un nœud de point d'entrée de tunnel doit prendre en charge la fragmentation des paquets tunnels IPv6.
Un nœud intermédiaire de tunnel qui transmet un paquet tunnel à un autre nœud dans le tunnel suit la règle générale IPv6 qu'il ne doit pas fragmenter un paquet qui subit une transmission.
Un nœud de point de sortie de tunnel qui reçoit des paquets tunnels à désencapsuler à la fin du tunnel applique strictement les règles de traitement de gauche à droite pour les en-têtes d'extension. Dans le cas d'un paquet tunnel fragmenté, les fragments sont réassemblés en un paquet tunnel complet avant de déterminer qu'un paquet incorporé est présent.
Note : Un problème particulier survient lorsque la destination d'un paquet tunnel fragmenté est un nœud de point de sortie identifié par une adresse d'envoi individuel. Le problème, qui est similaire à celui des paquets IPv6 originaux fragmentés destinés aux nœuds identifiés par une adresse d'envoi individuel, est que tous les fragments d'un paquet doivent arriver au même nœud de destination pour que ce nœud soit capable de réussir à effectuer le réassemblage, exigence qui n'est pas nécessairement satisfaite par les paquets envoyés à une adresse d'envoi individuel.
7.1 Fragmentation de paquet tunnel IPv6
Lorsque un paquet original IPv6 entre dans un tunnel, si la taille du paquet original excède la MTU de tunnel (c'est-à-dire, la MTU du chemin entre le point d'entrée de tunnel et le point de sortie de tunnel, moins la taille du ou des en-têtes de tunnels) il est traité comme suit :
(a) Si la taille du paquet IPv6 original est supérieure à la MTU de liaison IPv6 minimum [RFC2460], le nœud de point d'entrée élimine le paquet et envoie un message ICMPv6 "Paquet trop gros" à l'adresse de source du paquet original avec le champ Taille de MTU recommandée réglé au plus grand de la MTU du tunnel ou de la MTU de liaison IPv6 minimum, c'est-à-dire à max (MTU de tunnel, MTU de liaison IPv6 minimum). Voir aussi aux paragraphes 6.7 et 8.2.
(b) Si la taille du paquet IPv6 original est égale ou inférieure à la MTU de liaison IPv6 minimum, le nœud de point d'entrée de tunnel encapsule le paquet original, et fragmente ensuite le paquet tunnel IPv6 résultant en fragments IPv6 qui n'excèdent pas la MTU de chemin vers le point de sortie de tunnel.
7.2 Fragmentation de paquet tunnel IPv4
Lorsque un paquet original IPv4 entre dans un tunnel, si la taille du paquet original excède la MTU de tunnel (c'est-à-dire, la MTU de chemin entre le point d'entrée de tunnel et le point de sortie de tunnel, moins la taille du ou des en-têtes de tunnels) il est traité comme suit :
(a) Si dans l'en-tête du paquet IPv4 original le fanion binaire Ne pas fragmenter (DF, Don't Fragment) est établi (à un), le nœud de point d'entrée élimine le paquet et retourne un message ICMP. Le message ICMP a le type "injoignable", le code "paquet trop gros", et le champ "Taille de MTU recommandée" réglé à la taille de la MTU du tunnel - voir aux paragraphes 6.7 et 8.3.
(b) Si dans l'en-tête du paquet original le fanion binaire DF - est ôté (à 0), le nœud de point d'entrée de tunnel encapsule le paquet original, et fragmente ensuite le paquet tunnel IPv6 résultant en fragments IPv6 qui n'excèdent pas la MTU de chemin au point de sortie de tunnel.
8. Traitement et rapport d'erreur de tunnel IPv6
Le tunnelage IPv6 suit la règle générale selon laquelle une erreur détectée durant le traitement d'un paquet IPv6 est rapportée au moyen d'un message ICMP à la source du paquet.
Sur un chemin de transmission qui inclut des tunnels IPv6, une erreur détectée par un nœud qui n'est dans aucun tunnel est rapportée directement à la source du paquet original IPv6.
Une erreur détectée par un nœud à l'intérieur d'un tunnel est rapportée à la source du paquet tunnel, c'est à dire, au nœud de point d'entrée du tunnel. Le message ICMP envoyé au nœud de point d'entrée de tunnel a comme charge utile ICMP le paquet tunnel IPv6 qui a le paquet original comme charge utile.
La cause d'une erreur de paquet rencontrée à l'intérieur d'un tunnel peut être un problème avec :
(a) l'en-tête de tunnel,
(b) le paquet tunnel.
Les problèmes d'en-tête de tunnel et de paquet tunnel sont tous deux rapportés au nœud de point d'entrée de tunnel.
Si un problème de paquet tunnel est une conséquence d'un problème avec le paquet original, qui est la charge utile du paquet tunnel, le problème est alors aussi rapporté à la source du paquet original.
Pour rapporter un problème détecté à l'intérieur du tunnel à la source d'un paquet original, le nœud de point d'entrée du tunnel doit s'appuyer sur le message ICMP reçu de l'intérieur du tunnel à la source de ce paquet IPv6 original.
Un exemple du traitement qui peut avoir lieu dans le mécanisme de rapport d'erreur d'un nœud est illustré par les figures 7 et 8 :
Figure 7, chemin n° 0 et Figure 8 (a) - Le point d'entrée de tunnel IPv6 reçoit un paquet ICMP de l'intérieur du tunnel, marqué Message tunnel ICMPv6 dans la Figure 7. La couche de nœud de point d'entrée de tunnel IPv6 passe le message ICMP reçu à l'entrée ICMPv6. L'entrée ICMPv6, sur la base du type et code ICMP [RFC2463] génère un "code d'erreur" interne.
Figure 7, chemin n° 1 - Le code d'erreur interne est passé avec la "charge utile de message ICMPv6" au protocole de couche supérieure - dans ce cas, l'entrée d'erreur de couche supérieure du tunnel IPv6.
Entrée d'erreur de tunnel IPv6 de couche supérieure
Entrée d'erreur de protocole de couche supérieure
Figure 7 : Flux de rapport d'erreur dans un nœud (moteur de protocole de tunnelage IPv6)
Figure 7, chemin n° 2 et Figure 8 (b) – L'entrée d'erreur de tunnel IPv6 désencapsule le paquet tunnel IPv6, qui est la charge utile du message ICMPv6, obtenant le paquet original, et donc les en-têtes originaux, et expédie le "code d'erreur interne", l'adresse de source provenant de l'en-tête d'origine du paquet, et le paquet original, au bloc de rapport d'erreurs du protocole identifié par le champ Prochain en-tête dans l'en-tête de tunnel qui précède immédiatement le paquet original dans la charge utile du message ICMP.
À partir de là, le traitement dépend du protocole du paquet original :
(a) pour un paquet original IPv6
Figure 7, chemin n° 3 et Figure 8 (c.1) - pour un paquet original IPv6, le rapport d'erreur ICMPv6 construit un message ICMP d'un type et code conforme au "code d'erreur interne", contenant le "paquet original" comme charge utile ICPM.
Figure 7, chemin n° 4 et Figure 8 (d.1) - Le message ICMP a l'adresse du nœud de point d'entrée de tunnel comme adresse de source, et l'adresse du nœud de source du paquet original comme adresse de destination. Le nœud de point d'entrée de tunnel envoie le message ICMP au nœud de source du paquet original.
(b) pour un paquet original IPv4
Figure 7, chemin n° 5 et Figure 8 (c.2) - pour un paquet original IPv4, le rapport d'erreur ICMPv4 construit un message ICMP de type et code déduits du "code d'erreur interne", contenant le "paquet original" comme charge utile ICMP.
Figure 7, chemin n° 6 et Figure 8 (d.2) - Le message ICMP a l'adresse du nœud de point d'entrée de tunnel IPv4 comme adresse de source, et l'adresse du nœud de source du paquet original IPv4 comme adresse de destination. Le nœud de point d'entrée du tunnel envoie le message ICMP au nœud de source du paquet original.
La description graphique du traitement de l'en-tête qui a lieu est la suivante :
< Paquet tunnel >
+--------+- - - - - -+--------+------------------------------//------+
|En-tête | En-têtes | En-tête| Paquet tunnel |
(a)| |d'extension| | IPv6 |
| IPv6 | IPv6 | ICMP | erronné |
+--------+- - - - - -+--------+------------------------------//------+
<En-têtes de tunnel> < Message tunnel ICMP >
< Charge utile de message ICMPv6 >
|
v
< Message tunnel ICMP >
< Paquet tunnel IPv6 erronné >
+--------+ +---------+ +----------+--------//------+
|En-tête | | En-têtes| | En-têtes | Charge utile |
(b) | | + |de tunnel| + | | de paquet |
| ICMP | | IPv6 | | d'origine| original |
+--------+ +---------+ +----------+--------//------+
| < Paquet original erronné >
----------------- |
| |
--------------|---------------
| |
V V
+---------+ +--------+ +-------------------//------+
| Nouveaux| |En-tête | | |
(c.1) | en-têtes| + | | + | Paquet original erronné |
| IPv6 | | ICMP | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| Nouveaux|En-tête | |
(d.1) | en-têtes| | Paquet original erronné |
| IPv6 | ICMP | |
+---------+--------+-------------------//------+
< Nouveau message ICMP >
ou pour un paquet original IPv4
+---------+ +--------+ +-------------------//------+
| Nouvel | |En-tête | | |
(c.2) | en-tête | + | | + | Paquet original erronné |
| IPv4 | | ICMP | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| Nouvel | En-tête| |
(d.2) | en-tête | | Paquet original erronné |
| IPv4 | ICMP | |
+---------+--------+-------------------//------+
< Nouveau message ICMP >
Figure 8 : Rapport et traitement d'erreur ICMP
Les messages tunnels ICMP qui sont rapportés à la source du paquet original sont :
limite de bonds excédée
Le tunnel a une limite de bonds mal configurée, ou contient une boucle d'acheminement, et les paquets n'atteignent pas le nœud de point de sortie du tunnel. Ce problème est rapporté au nœud de point d'entrée du tunnel, où la limite de bonds de tunnel peut être reconfigurée à une valeur supérieure. Le problème est ensuite rapporté à la source du paquet original comme décrit aux paragraphes 8.2 ou 8.3.
nœud injoignable
Un des nœuds dans le tunnel n'est pas ou n'est plus joignable. Ce problème est rapporté au nœud de point d'entrée du tunnel, qui devrait reconfigurer avec un chemin valide et actif entre les points d'entrée et de sortie du tunnel. Le problème est ensuite rapporté à la source du paquet original comme décrit aux paragraphes 8.2 ou 8.3.
problème de paramètre
Un message ICMP Problème de paramètre pointant sur un en-tête valide Limite d'encapsulation du tunnel vers la destination avec une valeur du champ Limite d'encapsulation de tunnel réglée à un est une indication que le paquet tunnel a excédé le nombre maximum d'encapsulations permises. Le problème est ensuite rapporté à la source du paquet original comme décrit aux paragraphes 8.2 ou 8.3.
Les trois problèmes ci-dessus qui sont détectés à l'intérieur du tunnel, un problème de configuration de tunnel et un problème de topologie de tunnel, sont rapportés à la source du paquet original IPv6, comme un problème générique de tunnel "injoignable" causé par un "problème de liaison" - voir aux paragraphes 8.2 et 8.3.
paquet trop gros
Le paquet tunnel excède la MTU de chamin du tunnel.
Les informations portées par ce type de message ICMP sont utilisées comme suit :
- Par un nœud de point d'entrée de tunnel receveur pour régler ou ajuster la MTU de tunnel
- Par un nœud de point d'entrée de tunnel d'envoi pour indiquer à la source d'un paquet original la taille de MTU qui devrait être utilisée lors de l'envoi de paquets IPv6 vers le nœud de point d'entrée de tunnel.
8.2 Messages ICMP pour paquets d'origine IPv6
Le nœud de point d'entrée de tunnel construit les en-têtes ICMP et IPv6 du message ICMP qui est envoyé à la source du paquet original comme suit :
Champs IPv6 :
Adresse de source
Une adresse IPv6 d'envoi individuel valide de l'interface sortante.
Adresse de destination
Copiée du champ Adresse de source de l'en-tête original IPv6.
Champs ICMP:
Pour tous les messages tunnels d'erreur ICMP suivants :
"limite de bonds excédée"
"nœud injoignable"
"problème de paramètre" – pointant sur un en-tête valide Limite d'enccapsulation de tunnel de destination avec le champ Limite d'encapsulation de tunnel réglé à une valeur de zéro :
Type 1 – nœud injoignable
Code 3 - adresse injoignable
Pour le message d'erreur ICMP de tunnel "paquet trop gros" :
Type 2 - paquet trop gros
Code 0
MTU Le champ MTU du message tunnel ICMP moins la longueur des en-têtes de tunnel.
Selon les règles générales décrites au paragraphe 7.1, un message ICMP "paquet trop gros" n'est envoyé à la source du paquet original que si la taille du paquet original est supérieure à la taille minimum de MTU de liaison exigée pour IPv6 [RFC2460].
8.3 Messages ICMP pour paquets d'origine IPv4
Le nœud de point d'entrée de tunnel construit l'en-tête ICMP et IPv4 du message ICMP qui est envoyé à la source du paquet original comme suit :
Champs IPv4 :
Adresse de source
Une adresse IPv4 d'envoi individuel valide de l'interface de sortie.
Adresse de destination
Copiée du champ Adresse de source de l'en-tête original IPv4.
Champs ICMP :
Pour tous les messages tunnels d'erreur ICMP suivants :
"limite de bonds excédée"
"nœud injoignable"
"problème de paramètre" - pointant sur un en-tête valide Limite d'enccapsulation de tunnel de destination avec le champ Limite d'encapsulation de tunnel réglé à une valeur de zéro :
Type 3 - destination injoignable
Code 1 – hôte injoignable
Pour un message tunnel d'erreur ICMP "paquet trop gros" :
Type 3 - destination injoignable
Code 4 - paquet trop gros
MTU Le champ MTU provenant du message tunnel ICMP moins la longueur des en-têtes de tunnel.
Selon les règles générales décrites au paragraphe 7.2, un message ICMP "paquet trop gros" est envoyé au nœud de source du paquet original IPv4 si l'en-tête IPv4 original a le fanion binaire DF (ne pas fragmenter) établi (à 1).
8.4 Messages ICMP pour paquets tunnels incorporés
Dans le cas de découverte d'une erreur dans un paquet tunnel incorporé, le point d'entrée de tunnel le plus interne, qui reçoit le message d'erreur ICMP du nœud interne au tunnel qui fait le rapport, relaie le message ICMP au point d'entrée externe du tunnel suivant les mécanismes décrits à la Section 8. De plus, le point d'entrée externe du tunnel relaie le message ICMP à la source du paquet original, suivant les mêmes mécanismes.
9. Considérations pour la sécurité
Un tunnel IPv6 peut être sécurisé en sécurisant le chemin IPv6 entre le point d'entrée de tunnel et le nœud de point de sortie. L'architecture, les mécanismes, et les services de sécurité sont décrits dans les [RFC2401], [RFC2402], et [RFC2406]. Un tunnel IPv6 sécurisé peut agir comme un chemin sécurisé de passerelle à passerelle comme décrit dans la [RFC2401].
Pour un tunnel IPv6 sécurisé, en plus des mécanismes décrits plus tôt dans le présent document, le nœud de point d'entrée du tunnel exécute des algorithmes de sécurité sur le paquet et ajoute au titre de l'en-tête de tunnel un ou plusieurs en-têtes de sécurité conformément aux [RFC2460], [RFC2401], et [RFC2402], ou à la [RFC2406].
Le nœud de point de sortie d'un tunnel IPv6 sécurisé effectue les algorithmes de sécurité et traite le ou les en-têtes de sécurité du tunnel au titre du traitement des en-têtes de tunnel décrits antérieurement, et conformément à la [RFC2401], et à la [RFC2402], ou à la [RFC2406]. Le nœud de point de sortie élimine le ou les en-têtes de sécurité avec le reste des en-têtes de tunnel après l'achèvement du traitement des en-têtes de tunnel.
Le degré d'intégrité, d'authentification, et de confidentialité et le traitement de sécurité effectué sur un paquet tunnel au nœud de point d'entrée et au nœud de point de sortie d'un tunnel IPv6 sécurisé dépend du type d'en-tête de sécurité - authentification (AH) ou chiffrement (ESP) - et des paramètres configurés dans l'association de sécurité (AS) pour le tunnel. Il n'y a pas de dépendance ou d'interaction entre le niveau de sécurité et les mécanismes appliqués aux paquets tunnels et la sécurité appliquée aux paquets originaux qui sont les charges utiles des paquets tunnels. Dans le cas de tunnels incorporés, chaque tunnel interne peut avoir son propre ensemble de services de sécurité, indépendamment de ceux des tunnels externes, ou de ceux situés entre la source et la destination du paquet original.
Le présent document découle partiellement de plusieurs discussions sur les tunnels IPv6 dans la liste de diffusion du groupe de travail IPng et de réactions du groupe de travail IPng à une présentation IPv6 centrée sur la tunnelisation IPv6 à la 33 ème réunion de l'IETF, à Stockholm, en juillet 1995.
De plus, les documents suivants qui sont centrés sur le tunnelage ou l'encapsulation ont été des références utiles : RFC 1933 (R. Gilligan, E. Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. Simpson), ainsi que la RFC 2003 (C. Perkins).
Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik Nordmark (par ordre alphabétique) ont apporté de précieux commentaires et suggestions pour l'amélioration du présent document. Scott Bradner, Ross Callon, Dimitry Haskin, Paul Traina, et James Watt (par ordre alphabétique) nous ont fait bénéficier de leurs idées ou de leur expérience sur les sujets traités dans ce document. Judith Grossman nous a donné un échantillon de ce que peuvent donner de nombreuses années d'expérience de rédaction et de relecture ainsi que de vérification des questions techniques.
(Les liens sur les numéros pointent sur la version originale anglaise, ceux du corps du titre sur la traduction française)
[RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre 1998. (MàJ par RFC5095, D.S)[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", décembre 1998. (Obsolète, voirRFC4861)(D.S.)
[RFC2463] A. Conta, S. Deering, "Protocole de message de contrôle Internet (ICMPv6) pour le protocole Internet version 6 (IPv6)", décembre 1998. (Obsolète, voirRFC4443)(D.S.)
[RFC1981] J. McCann, S. Deering, J. Mogul, "Découverte de la MTU de chemin pour IP version 6", août 1996. (P.S.)
[RFC2401] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voirRFC4301)
[RFC2402] S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)
[RFC2406] S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité IP (ESP)", novembre 1998. (Obsolète, voir RFC4303)
[RFC1853] W. Simpson, "Tunnel IP dans IP", octobre 1995. (Information)
[RFC1700] J. Reynolds et J. Postel, "Numéros alloués", STD 2, octobre 1994. (Historique) Voir http://www.iana.org/numbers.html
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
Alex Conta |
Stephen Deering |
Lucent Technologies Inc. |
Cisco Systems |
300 Baker Ave |
170 West Tasman Dr |
Concord, MA 01742-2168 |
San Jose, CA 95132-1706 |
téléphone :+1-978-287-2842 |
téléphone : +1-408-527-8213 |
mél : aconta@lucent.com |
mél : deering@cisco.com |
Appendice A Facteurs de risque
A.1 Facteurs de risque dans l'encapsulation incorporée
Les encapsulations incorporées d'un paquet deviennent une encapsulation récurrente si le paquet rentre dans un tunnel externe avant d'en sortir. Le cas qui présente un fort risque d'encapsulation récurrente est celui dans lequel un nœud de point d'entrée de tunnel ne peut pas déterminer si un paquet qui subit une encapsulation rentre dans le tunnel avant d'en sortir. Les boucles d'acheminement qui causent la rentrée de paquets tunnels dans un tunnel avant qu'ils en soient sortis sont certainement la cause majeure du problème. Mais comme les boucles d'acheminement existent et arrivent, il est important de comprendre et décrire les cas dans lesquels le risque d'encapsulation récurrente est plus fort.
Il y a deux éléments significatifs qui déterminent le facteur de risque d'encapsulation récurrente dans une boucle d'acheminement :
(a) le type de tunnel,
(b) le type de chemin vers le point de sortie de tunnel, qui détermine la transmission du paquet à travers le tunnel, c'est à dire, sur la liaison virtuelle du tunnel.
Les types de tunnel qui ont été identifiés comme présentant un facteur de risque fort d'encapsulation récurrente dans des boucles d'acheminement sont les "tunnels internes avec des points de sortie identiques".
Comme la source et la destination d'un paquet original sont les principales informations utilisées pour décider de transmettre ou non un paquet à travers un tunnel, une encapsulation récurrente peut être évitée dans le cas d'un seul tunnel (non interne) en vérifiant que le paquet à encapsuler n'est pas généré sur le nœud de point d'entrée. Ce mécanisme est suggéré dans la [RFC1853].
Cependant, ce type de protection ne semble pas bien fonctionner dans le cas de tunnels internes avec des points d'entrée différents, et des points de sortie identiques.
Les tunnels internes avec des points d'entrée différents et des points de sortie identiques introduisent une ambiguïté dans la décision d'encapsuler ou non un paquet, lorsque un paquet encapsulé dans un tunnel interne atteint le nœud de point d'entrée d'un tunnel externe au moyen d'une boucle d'acheminement. Comme la source du paquet tunnel est le nœud de point d'entrée de tunnel interne qui est différent du nœud de point d'entrée du tunnel externe, la vérification de l'adresse de source (mentionnée ci-dessus) ne réussit pas à détecter une encapsulation invalide, et par conséquent le paquet tunnel se trouve encapsulé au tunnel externe chaque fois qu'il l'atteint à travers la boucle d'acheminement.
Le type de chemin vers un nœud de point de sortie de tunnel a aussi été identifié comme un facteur de risque élevé d'encapsulation récurrente dans des boucles d'acheminement.
Un type de chemin vers un nœud de point de sortie de tunnel serait un chemin vers un nœud de destination spécifié, c'est à dire que la destination est une adresse IPv6 spécifiée valide (chemin vers le nœud). Un tel chemin peut être choisi sur la base de la plus longue correspondance de l'adresse de destination d'un paquet original avec l'adresse de destination mémorisée dans l'entrée du tableau d'acheminement du nœud de point d'entrée du tunnel pour ce chemin. Le paquet transmis sur un tel chemin est d'abord encapsulé puis transmis vers le nœud de point de sortie du tunnel.
Un autre type de chemin vers un nœud de point de sortie de tunnel est un chemin pour un préfixe de réseau spécifié, c'est à dire que la destination est un préfixe IPv6 spécifié valide (chemin vers un réseau). Un tel chemin peut être choisi sur la base de la plus longue correspondance de chemin de l'adresse de destination d'un paquet original avec le préfixe de la destination mémorisée dans l'entrée du tableau d'acheminement du nœud de point d'entrée du tunnel pour ce chemin. Le paquet transmis sur un tel chemin est d'abord encapsulé puis transmis vers le nœud de point de sortie du tunnel.
Et finalement un autre type de chemin vers un point de sortie de tunnel est un chemin par défaut, ou un chemin vers une destination non spécifiée. Ce chemin est choisi lorsque aucune autre correspondance n'a été trouvée dans le tableau d'acheminement pour la destination du paquet original. Un tunnel qui est le premier bond d'un chemin par défaut est un "tunnel par défaut".
Si le chemin vers un point de sortie de tunnel est un chemin vers un nœud, le risque d'encapsulation récurrente est minimum.
Si le chemin vers un point de sortie de tunnel est un chemin vers un réseau, le facteur de risque d'encapsulation récurrente est moyen. Il y a une gamme d'adresses de destination qui vont correspondre au préfixe auquel le chemin est associé. Si un ou plusieurs tunnels internes avec des point d'entrée de tunnels différents ont des adresses de nœud de point de sortie qui correspondent au chemin vers le réseau d'un point de sortie de tunnel externe, une encapsulation récurrente peut alors survenir si un paquet tunnel se trouve détourné de l'intérieur d'un tel tunnel interne vers le point d'entrée du tunnel externe qui a un chemin vers son point de sortie qui correspond au point de sortie d'un tunnel interne.
Si le chemin vers un point de sortie de tunnel est un chemin par défaut, le facteur de risque d'encapsulation récurrente est maximum. Les paquets sont transmis à travers un tunnel par défaut par manque d'un meilleur chemin. Dans de nombreuses situations, la transmission à travers un tunnel par défaut peut survenir avec une large gamme d'adresses de destination qui dans son extension maximum est l'Internet entier moins la liaison du nœud. Par conséquent, il est vraisemblable que dans le cas d'une boucle d'acheminement, si un paquet tunnel se trouve détourné d'un tunnel interne vers un point d'entrée de tunnel externe dans lequel le tunnel est un tunnel par défaut, le paquet sera encapsulé une fois de plus, parce que le mécanisme d'acheminement par défaut ne sera pas capable de faire un meilleur choix, sur la base de la destination.
Déclaration complète de droits de propriété intellectuelle
Copyright (C) The Internet Society (1998). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY et L'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.