IPv6 QO - Revision history

Jprioual: /* Extensions */

2015-06-24T06:44:35Z

‎Extensions

Jprioual: /* Extentions */

2015-06-24T06:42:49Z

‎Extentions

Jprioual: /* Options dans les extensions */

2015-06-24T06:36:05Z

‎Options dans les extensions

Ltoutain at 06:49, 7 March 2011

2011-03-07T06:49:27Z

Ltoutain at 01:45, 11 February 2010

2010-02-11T01:45:38Z

Ltoutain: /* Sécurité */

2010-02-11T01:34:59Z

‎Sécurité

Ltoutain at 01:33, 11 February 2010

2010-02-11T01:33:18Z

Ltoutain: /* Sécurité */

2010-02-11T01:14:08Z

‎Sécurité

Ltoutain: /* Extentions */

2010-02-11T01:12:41Z

‎Extentions

Ltoutain at 01:08, 11 February 2010

2010-02-11T01:08:42Z

@@ Line 4: / Line 4: @@
 =Extensions=
-==Traitement optimisé des extentions==
+==Traitement optimisé des extensions==
 <tikz title="Traitement de l'option LSR en IPv4" scale="75%">
@@ Line 59: / Line 59: @@
 </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);
@@ Line 115: / Line 115: @@
 <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.
-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/>
-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);
@@ Line 181: / Line 181: @@
 *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 extensions==

← Older revision		Revision as of 06:42, 24 June 2015
Line 2:		Line 2:


−	=~~Extentions~~=	+	=Extensions=

	==Traitement optimisé des extentions==		==Traitement optimisé des extentions==

@@ Line 187: / Line 187: @@
 De même l'extention 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);
@@ Line 210: / Line 210: @@
 </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}}
-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> ===
@@ Line 310: / Line 310: @@
 ** 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'extention Hop-By-Hop nuit a l'efficacité du relayage des paquets.
+* 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.
@@ Line 352: / Line 352: @@
 === <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]]).
@@ Line 358: / 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.
-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'extention 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'extention RH2. Le nœud mobile reçoit le paquet IPv6, traite l'extention 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.
+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">

@@ Line 1: / Line 1: @@
 =Extentions=
@@ Line 425: / Line 428: @@
 === 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.

← Older revision		Revision as of 01:45, 11 February 2010
Line 425:		Line 425:
	=== 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 4302 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.
−
−	~~==Flow Label==~~

← Older revision		Revision as of 01:33, 11 February 2010
Line 430:		Line 430:
	.		.

−	=Flow Label=	+	==Flow Label==

← Older revision		Revision as of 01:14, 11 February 2010
Line 427:		Line 427:

	{{ToDo\|Firewall et extentions}}		{{ToDo\|Firewall et extentions}}
		+
		+	.

	=Flow Label=		=Flow Label=

← Older revision		Revision as of 01:12, 11 February 2010
Line 427:		Line 427:

	{{ToDo\|Firewall et extentions}}		{{ToDo\|Firewall et extentions}}
−

	=Flow Label=		=Flow Label=

← Older revision		Revision as of 01:08, 11 February 2010
Line 427:		Line 427:

	{{ToDo\|Firewall et extentions}}		{{ToDo\|Firewall et extentions}}
		+

	=Flow Label=		=Flow Label=