MOOC:Compagnon Act21-s7 - Revision history

Jlandru at 14:24, 6 November 2024

2024-11-06T14:24:48Z

Panelli: /* Annexe 1: la gestion de la qualité de service */

2023-12-15T11:21:12Z

‎Annexe 1: la gestion de la qualité de service

Bstevant: /* Pour aller plus loin */

2023-01-10T08:08:06Z

‎Pour aller plus loin

Bstevant: /* Annexe 1: la gestion de la qualité de service */

2023-01-08T22:35:42Z

‎Annexe 1: la gestion de la qualité de service

Bstevant: /* Version */

2023-01-08T22:31:38Z

‎Version

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

2022-02-18T16:45:58Z

‎Annexe 2: Le mécanisme d’extension de l'en-tête IPv6

Jprioual: /* Conclusion */

2022-02-18T16:44:41Z

‎Conclusion

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

2022-02-18T16:41:49Z

‎Annexe 2: Le mécanisme d’extension de l'en-tête IPv6

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

2022-02-18T16:41:34Z

‎Annexe 2: Le mécanisme d’extension de l'en-tête IPv6

Show changes

Jprioual: /* Annexe 1: la gestion de la qualité de service */

2022-02-18T16:39:32Z

‎Annexe 1: la gestion de la qualité de service

← Older revision		Revision as of 14:24, 6 November 2024
Line 279:		Line 279:
	* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]		* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
	* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]		* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]
		+	* RFC 9673 : IPv6 Hop-by-Hop Options Processing Procedures [http://www.bortzmeyer.org/9673.html Analyse]

@@ Line 150: / Line 150: @@
 * Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées.  La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).
-* Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).
+* Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).
 * Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].

@@ Line 103: / Line 103: @@
 RFC et leur analyse par S. Bortzmeyer :
 * RFC 791 Internet protocol (IPv4)
 * RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
 * RFC 2205 Resource ReSerVation Protocol (RSVP)

@@ Line 149: / Line 149: @@
 * Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.
-* Expedited Forwarding [[https://tools.ietf.org/html/rfc2598#page-1 RFC 2598]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées.  La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).
+* Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées.  La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).
 * Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).
@@ Line 157: / Line 157: @@
 === Références bibliographiques ===
 * RFC 2597 Assured Forwarding PHB Group
-* RFC 2598  An Expedited Forwarding PHB
+* RFC 3246  An Expedited Forwarding PHB
 * RFC 4594 Configuration Guidelines for DiffServ Service Classes
 * RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic

@@ Line 22: / Line 22: @@
 === Version ===
-Le champ <tt>Version</tt> est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu.  Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1190, RFC 1819].
+Le champ <tt>Version</tt> est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu.  Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].
 === Classe de trafic (''Traffic Class'') ===

← Older revision		Revision as of 16:45, 18 February 2022
Line 168:		Line 168:

	Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.		Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.
		+
		+	Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.
		+
		+	L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

	== Principe des extensions IPv6==		== Principe des extensions IPv6==

← Older revision		Revision as of 16:44, 18 February 2022
Line 260:		Line 260:

	Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.		Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.
−
−	~~== Conclusion ==~~
−	Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.
−
−	L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

	== Références bibliographiques ==		== Références bibliographiques ==

← Older revision		Revision as of 16:41, 18 February 2022
Line 168:		Line 168:

	Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.		Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.
−

	== Principe des extensions IPv6==		== Principe des extensions IPv6==

← Older revision		Revision as of 16:39, 18 February 2022
Line 160:		Line 160:
	* RFC 4594 Configuration Guidelines for DiffServ Service Classes		* RFC 4594 Configuration Guidelines for DiffServ Service Classes
	* RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic		* RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
		+
		+	== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==