MOOC:Compagnon Act20-s7 - Revision history

Bstevant: /* Pour aller plus loin */

2023-01-10T08:12:01Z

‎Pour aller plus loin

Bstevant: /* Pour aller plus loin */

2023-01-10T08:09:58Z

‎Pour aller plus loin

Bstevant: /* Pour aller plus loin */

2023-01-08T22:30:06Z

‎Pour aller plus loin

Bstevant: /* SCTP */

2023-01-08T22:27:28Z

‎SCTP

Bstevant: /* UDP et TCP */

2023-01-08T22:26:13Z

‎UDP et TCP

Jprioual: /* Conclusion */

2022-02-18T16:32:23Z

‎Conclusion

Jprioual: /* Introduction de la séquence 2 */

2022-02-18T16:31:40Z

‎Introduction de la séquence 2

Jprioual: /* Conclusion */

2022-02-18T16:31:22Z

‎Conclusion

Jprioual: /* Conclusion */

2022-02-18T16:25:13Z

‎Conclusion

Jprioual: /* Couche liaison */

2022-02-18T16:23:26Z

‎Couche liaison

@@ Line 226: / Line 226: @@
 * RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) [http://www.bortzmeyer.org/3828.html Analyse]
 * RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
 * RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.html Analyse]
 * RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse], depuis intégrées dans les spécifications de TCP dans le RFC 9293
@@ Line 234: / Line 233: @@
 * RFC 7323 : TCP Extensions for High Performance [http://www.bortzmeyer.org/7323.html Analyse]
 * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]

@@ Line 222: / Line 222: @@
 == Pour aller plus loin==
 RFC et leur analyse par S. Bortzmeyer :
 * RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks
 * RFC 2675 : IPv6 Jumbograms
@@ Line 233: / Line 232: @@
 * RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]
 * RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]
 * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]

@@ Line 229: / Line 229: @@
 * RFC 4960 Stream Control Transmission Protocol [http://www.bortzmeyer.org/4960.html Analyse]
 * RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.html Analyse]
-* RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse]
+* RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse], depuis intégrées dans les spécifications de TCP dans le RFC 9293
 * RFC 6935: IPv6 and UDP Checksums for Tunneled Packets [http://www.bortzmeyer.org/6935.html Analyse]
 * RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]
 * RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]
 * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]

@@ Line 184: / Line 184: @@
 ==== SCTP ====
-Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 4960 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation<ref>Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April.
+Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 9260 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation<ref>Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April.
 SCTP: State of the Art in Research, Products, and Technical Challenges.</ref>. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux nœuds d'extrémité d'échanger, à l'initialisation de la connexion (appelée, dans le standard, ''association''), l'ensemble de leurs adresses IPv4 et IPv6. Chaque nœud choisit une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si le nœud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie.

@@ Line 167: / Line 167: @@
 * pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ <tt>longueur</tt> est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option ''jumbogramme'' ;
 * le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ <tt>longueur</tt>, plusieurs compteurs sont codés sur 16 bits ;
-* le champ <tt>longueur</tt> de la fenêtre de réception ne pose pas de problème depuis que le RFC 1323 a défini l'option ''TCP window scale'' qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;
+* le champ <tt>longueur</tt> de la fenêtre de réception ne pose pas de problème depuis que le RFC 7323 a défini l'option ''TCP window scale'' qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;
 * à l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que, si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU.

@@ Line 191: / Line 191: @@
 == Conclusion ==
-Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport. Même si ces couches sont censées être indépendantes dans le modèle théorique OSI, force est de remarquer que dans la pratique, elles sont interdépendantes.
+Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport.
 Pour preuve le champ de contrôle d'erreur n'a pas été retenu au niveau de la couche IP  car il y a déjà un contrôle fait au niveau ''liaison''. Et un autre contrôle d'erreur a été  placé dans les couches supérieures afin de vérifier l'intégrité des données transportées. Cette vérification se fait uniquement par le destinataire. Le contrôle d'erreur est un exemple qui illustre  l'interdépendance des couches.

← Older revision		Revision as of 16:31, 18 February 2022
Line 232:		Line 232:
	* RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]		* RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]
	* 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]
−
−
−	~~== Introduction de la séquence 2 ==~~
−
−	Dans la première séquence, les différents types d'adresses IPv6 ont été présentés. Cette deuxième séquence va détailler les mécanismes protocolaires. Le fil rouge est la performance du traitement des datagrammes dans tous les équipements et en particulier les équipements intermédiaires tels que les routeurs ou les pare-feux.
−
−	~~<!--~~
−	~~Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de quatre activités thématiques :~~
−	* A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;
−	* A22 : puis, vous aborderez les principes de l'acheminement et du routage ;
−	* A23 : ensuite, les points essentiels sur la détermination des tailles de paquets vous seront exposés ;
−	* A24 : ensuite, vous seront exposés les mécanismes d’encapsulation ;
−	* A25 : Dans cette activité, vous décomposerez les extensions de l’en-tête IP par le biais d'exemples ;
−	* A26 : enfin, vous pourrez observer l'acheminement de paquets IPv6 au moyen de cette activité pratique. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez pratiquer la communication IPv6 sans déstabiliser la configuration de votre ordinateur. -->
−	~~Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de cinq activités thématiques :~~
−	* A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;
−	* A22 : puis, vous aborderez les principes de l'acheminement et du routage ;
−	* A23 : ensuite, les points essentiels de contrôle et diagnostic de l'acheminement par ICMPv6 ;
−	* A24 : et enfin, vous décomposerez les extensions de l’en-tête IP par le biais de l'exemple de gestion de taille des paquets ;
−	* Activité pratique : en complément vous pourrez observer l'acheminement de paquets IPv6. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez expérimenter la communication IPv6 sans déstabiliser la configuration de votre ordinateur.

@@ Line 119: / Line 119: @@
 L'unité de données de protocole de la couche ''liaison de données'' est la trame (''Link Protocol Data Unit'' (LPDU)), qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, le contenu de l’enveloppe et, en fin de trame, le champ CRC, le tout étant encadré par une séquence particulière de codage de début et de fin de trame.
-Si nous prenons l’exemple de la trame Ethernet (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.
+Si nous prenons l’exemple de la trame Ethernet originale (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.
 <center>
 [[image:2015 10 12 Ethernet v01.jpg|thumb|center|600px|Figure 2 : Format de la trame Ethernet.]]