MOOC:Compagnon Act23-s7 - Revision history

Bstevant: /* En-tête redirigée */

2022-04-19T22:31:39Z

‎En-tête redirigée

Bstevant: /* Pour aller plus loin */

2022-02-25T14:36:57Z

‎Pour aller plus loin

Jprioual: /* Fonctions autres et expérimentales */

2022-02-18T17:25:22Z

‎Fonctions autres et expérimentales

Jprioual: /* Annexe 1 */

2022-02-18T17:21:40Z

‎Annexe 1

Jprioual: /* Pour aller plus loin */

2022-02-18T17:20:52Z

‎Pour aller plus loin

Jprioual: /* Attention au filtrage d'ICMPv6 */

2022-02-18T17:13:31Z

‎Attention au filtrage d'ICMPv6

Jprioual: /* Pour aller plus loin */

2022-02-18T17:12:36Z

‎Pour aller plus loin

Jprioual: /* Pour aller plus loin */

2022-02-18T17:10:13Z

‎Pour aller plus loin

Jprioual: /* Attention au filtrage d'ICMPv6 */

2022-02-18T17:09:55Z

‎Attention au filtrage d'ICMPv6

Jprioual: /* Introduction */

2022-02-18T17:05:05Z

‎Introduction

@@ Line 352: / Line 352: @@
 === <div id="redirigee">En-tête redirigée</div> ===
-[[Image:31-Afig3.png|400px|right|thumb|Figure : Format de l'option en-tête redirigée.]]
+[[Image:31-Afig3-2.png|400px|right|thumb|Figure : Format de l'option en-tête redirigée.]]
 Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

@@ Line 208: / Line 208: @@
 * RFC 1191 Path MTU Discovery
 * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
 * RFC 4443 Internet Control Message Protocol (ICMPv6)  for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]
 * RFC 4620 IPv6 Node Information Queries
@@ Line 214: / Line 213: @@
 * RFC 8201 Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
 * RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits [http://www.bortzmeyer.org/8883.html Analyse]
 == Annexe 1 : Autres fonctions d'ICMPv6==

← Older revision		Revision as of 17:25, 18 February 2022
Line 336:		Line 336:
	</center>		</center>

		+	=== <div id="physique">Adresse physique de la source/cible</div> ===
		+
		+	[[Image:31-Afig1.png\|400px\|right\|thumb\|Figure : Format de l'option adresse physique source/cible.]]
		+
		+	La figure "Format de l'option adresse physique source/cible" donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.
		+
		+	Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.
		+
		+	Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.
		+
		+	=== <div id="information">Information sur le préfixe</div> ===
		+
		+	[[Image:31-Afig2.png\|400px\|right\|thumb\|Figure : Format de l'option information sur le préfixe.]]
		+
		+	Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.
		+
		+	=== <div id="redirigee">En-tête redirigée</div> ===
		+
		+	[[Image:31-Afig3.png\|400px\|right\|thumb\|Figure : Format de l'option en-tête redirigée.]]
		+
		+	Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.
		+
		+	Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.
		+
		+	=== <div id="MTU">MTU</div> ===
		+
		+	[[Image:31-Afig4.png\|400px\|right\|thumb\|Figure : Format de l'option MTU.]]
		+
		+	Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.
		+
		+	Le champ type vaut 5 et le champ longueur 1.

	== Pour aller plus loin==		== Pour aller plus loin==

@@ Line 216: / Line 216: @@
-== Annexe 1 ==
+== Annexe 1 : Autres fonctions d'ICMPv6==
 Le contenu de cette annexe complète l'activité 23 en :
 * introduisant MLD, le protocole de gestion des inscriptions aux groupes de ''multicast'' et les messages ICMPv6 associés ;

@@ Line 214: / Line 214: @@
 * RFC 8201 Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
 * RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits [http://www.bortzmeyer.org/8883.html Analyse]
 == Référence bibliographique ==
 <references />

← Older revision		Revision as of 17:13, 18 February 2022
Line 202:		Line 202:

	Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.		Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.
		+
		+	== Pour aller plus loin==
		+
		+	RFC et leur analyse par S. Bortzmeyer :
		+	* RFC 1191 Path MTU Discovery
		+	* RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
		+	* RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
		+	* RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]
		+	* RFC 4620 IPv6 Node Information Queries
		+	* RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
		+	* RFC 8201 Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
		+	* RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits [http://www.bortzmeyer.org/8883.html Analyse]
		+
		+	== Référence bibliographique ==
		+	<references />

← Older revision		Revision as of 17:12, 18 February 2022
Line 202:		Line 202:

	Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.		Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.
−
−	~~== Pour aller plus loin==~~
−
−	~~RFC et leur analyse par S. Bortzmeyer :~~
−	* RFC 1191 Path MTU Discovery
−	* RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
−	* RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
−	* RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]
−	* RFC 4620 IPv6 Node Information Queries
−	* RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
−	* RFC 8201 Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
−	* RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits [http://www.bortzmeyer.org/8883.html Analyse]

← Older revision		Revision as of 17:10, 18 February 2022
Line 204:		Line 204:

	== Pour aller plus loin==		== Pour aller plus loin==
−	~~{{TODO\|Restreindre cette liste car elle va plus loin que NDP}}~~

	RFC et leur analyse par S. Bortzmeyer :		RFC et leur analyse par S. Bortzmeyer :

← Older revision		Revision as of 17:09, 18 February 2022
Line 202:		Line 202:

	Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.		Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.
		+
		+	== Pour aller plus loin==
		+	{{TODO\|Restreindre cette liste car elle va plus loin que NDP}}
		+
		+	RFC et leur analyse par S. Bortzmeyer :
		+	* RFC 1191 Path MTU Discovery
		+	* RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
		+	* RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
		+	* RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]
		+	* RFC 4620 IPv6 Node Information Queries
		+	* RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
		+	* RFC 8201 Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
		+	* RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits [http://www.bortzmeyer.org/8883.html Analyse]

@@ Line 5: / Line 5: @@
 ==Introduction==
-Les réseaux physiques constituant Internet sont susceptibles d'être défaillants de manière plus ou moins fréquentes. Il peut s'agir d'une panne d'un équipement intermédiaire (routeur, commutateur) ou d'un lien (rupture d'un câble souterrain par une pelleteuse par exemple). L'internet est normalement prévu pour exploiter des chemins alternatifs pour continuer à assurer l'acheminement des paquets, mais la détection et la gestion de ces incidents nécessitent des mécanismes de contrôle. Le réseau peut aussi détecter des problèmes d'acheminement liés à la nature de certains paquets : taille des données trop importante, en-tête comportant une adresse invalide ou ne correspondant à aucun équipement, etc.
+Les réseaux physiques constituant Internet sont susceptibles d'être défaillants de manière plus ou moins fréquentes. Il peut s'agir d'une panne d'un équipement intermédiaire (routeur, commutateur) ou d'un lien (rupture d'un câble souterrain par une pelleteuse par exemple). L'Internet est normalement prévu pour exploiter des chemins alternatifs pour continuer à assurer l'acheminement des paquets, mais la détection et la gestion de ces incidents nécessitent des mécanismes de contrôle. Le réseau peut aussi détecter des problèmes d'acheminement liés à la nature de certains paquets : taille des données trop importante, en-tête comportant une adresse invalide ou ne correspondant à aucun équipement, etc.
 Le protocole IPv6 prévoit donc un mécanisme permettant de signaler ces problèmes d'acheminement. Les messages correspondant à cette signalisation sont spécifiés dans le protocole ICMPv6 (RFC 4443). Il permet au réseau d'informer la source d'un paquet que celui ne peut pas être acheminé et en signifie la raison. C'est un mécanisme similaire au retour à l'expéditeur dans le réseau postal.