MOOC:Compagnon Act24-s6 - Revision history

Bstevant: Bstevant moved page MOOC:Compagnon Act24 to MOOC:Compagnon Act24-s6

2021-06-15T14:07:13Z

Bstevant moved page MOOC:Compagnon Act24 to MOOC:Compagnon Act24-s6

Vlerouvillois: /* Conclusion */

2019-06-08T07:40:49Z

‎Conclusion

Vlerouvillois: /* SCTP */

2019-06-08T07:39:58Z

‎SCTP

Vlerouvillois: /* UDP et TCP */

2019-06-08T07:37:30Z

‎UDP et TCP

Vlerouvillois: /* Couche réseau */

2019-06-08T07:34:11Z

‎Couche réseau

Vlerouvillois: /* Traitement des couches basses */

2019-06-08T07:32:12Z

‎Traitement des couches basses

Vlerouvillois: /* Introduction */

2019-06-08T07:26:54Z

‎Introduction

Jlandru at 08:03, 24 May 2019

2019-05-24T08:03:19Z

Jlandru at 08:01, 24 May 2019

2019-05-24T08:01:28Z

Jlandru at 08:00, 24 May 2019

2019-05-24T08:00:55Z

@@ Line 108: / Line 108: @@
 == 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 noeuds 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. 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.
 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.

@@ Line 102: / Line 102: @@
 ==== 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.
-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 noeuds 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 noeud 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 noeud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie.
+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.
-SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du noeud et l'identification des associations.
+SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du nœud et l'identification des associations.
 == Conclusion ==

@@ Line 79: / Line 79: @@
 La principale modification de ces protocoles concerne le calcul de la somme de contrôle (''checksum'') pour vérifier l'intégrité des données. Comme la couche ''réseau'' ne possède pas de champ de contrôle, c'est à la couche de transport que revient cette tâche. Le calcul de la somme de contrôle au niveau du transport a donc été adapté pour inclure des données de l'en-tête. De plus, la présence d'une somme de contrôle devient obligatoire pour tout protocole de niveau supérieur transporté au-dessus d'IPv6.
-'''''Nota : ''''' ''Les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : "par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du noeud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle."''
+'''''Nota : ''''' ''les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : "par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du nœud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle."''
 Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option ''jumbogramme'' de l'extension ''proche-en-proche''. Le RFC 2675 définit le comportement d’UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ <tt>longueur</tt> codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :
-* 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''.
+* 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 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 1323 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.
+* à 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.
 Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête TCP (bit <tt>URG</tt>) ainsi que le champ <tt>pointeur urgent</tt>. Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :
-* Le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535.
+* le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535 ;
-* Le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ <tt>pointeur urgent</tt> et on continue le traitement normal des paquets TCP.
+* le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ <tt>pointeur urgent</tt> et on continue le traitement normal des paquets TCP ;
-* Le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ <tt>pointeur urgent</tt>. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535.
+* le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ <tt>pointeur urgent</tt>. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535.
 Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout en bout. La transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.

@@ Line 63: / Line 63: @@
 Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui, les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle au niveau réseau a diminué et ce champ a été supprimé de l'en-tête IPv6.
-Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en oeuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de ''pseudo-en-tête'' dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire.
+Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en œuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de ''pseudo-en-tête'' dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire.
 IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Le RFC 8200 définit, dans sa section 8.1, un ''pseudo-en-tête'' (cf. Figure 3), résultat de la concaténation d'une partie de l'en-tête IPv6 et du PDU du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en œuvre et ne demande pas d'opérations complexes. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du ''pseudo-en-tête'', de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.
@@ Line 69: / Line 69: @@
 [[image:Fig4-10.png|thumb|center|500px|Figure 3 : Champs du <tt>pseudo-en-tête</tt>.]]
 </center>
-Il faut noter que les informations contenues dans le ''pseudo-en-tête'' ne seront pas émises telles quelles sur le réseau. Le champ <tt>en-tête suivant</tt> du ''pseudo-en-tête'' ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier noeud. De même, le champ <tt>longueur</tt> est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.
+Il faut noter que les informations contenues dans le ''pseudo-en-tête'' ne seront pas émises telles quelles sur le réseau. Le champ <tt>en-tête suivant</tt> du ''pseudo-en-tête'' ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier nœud. De même, le champ <tt>longueur</tt> est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.
 === Couches Transport ===

@@ Line 15: / Line 15: @@
 == Traitement des couches basses==
-La méthode de transfert d'un datagramme IPv6 entre deux noeuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (''Protocol Data Unit'') de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du noeud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le noeud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.
+La méthode de transfert d'un datagramme IPv6 entre deux nœuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (''Protocol Data Unit'') de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du nœud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le nœud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.
 Les différences avec IPv4 sont les suivantes :
-* Sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ <tt>EtherType</tt> d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est <tt>0x86DD</tt> alors que, pour IPv4, le code est <tt>0x0800</tt>. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ <tt>Version</tt> du paquet. Mais certains noeuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4.
+* sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ <tt>EtherType</tt> d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est <tt>0x86DD</tt> alors que, pour IPv4, le code est <tt>0x0800</tt>. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ <tt>Version</tt> du paquet. Mais certains nœuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4 ;
-* La résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3.
+* la résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3 ;
-* La taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6.
+* la taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6 ;
-* Enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.
+* enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.
 === Couche physique ===

← Older revision	Revision as of 14:07, 15 June 2021
(No difference)

@@ Line 3: / Line 3: @@
 {{Approfondissement}}
 ==Introduction==
-La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les noeuds d’extrémité, et certaines seulement pour les noeuds intermédiaires.
+La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les nœuds d’extrémité, et certaines seulement pour les nœuds intermédiaires.
-L’organisation internationale de normalisation ISO a défini le modèle OSI (''Open System Interconnection'') par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la Figure 1. Le modèle TCP/IP (ou DOD ''Department of Defense'') a eu une approche plus pragmatique en décomposant l'architecture de réseau  en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.
+L’organisation internationale de normalisation ISO a défini le modèle OSI (''Open System Interconnection'') par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la figure 1. Le modèle TCP/IP (ou DOD ''Department of Defense'') a eu une approche plus pragmatique en décomposant l'architecture de réseau en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.
 <center>
 [[image:2015_10_12_Encapsulation_v01.jpg|thumb|center|500px|Figure 1 : Comparaison modèle OSI - modèle TCP/IP.]]
 </center>
-Pour simplifier l’organisation, pour un noeud d'extrémité du réseau, nous pouvons considérer, que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.
+Pour simplifier l’organisation, pour un nœud d'extrémité du réseau, nous pouvons considérer que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.
-Cette activité  vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (''Maximum Transmission Unit'' (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires).  La question de la détection d'erreur binaire se pose dans la mesure que le calcul de redondance a disparu de l'en-tête IPv6.
+Cette activité vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (''Maximum Transmission Unit'' (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires).  La question de la détection d'erreur binaire se pose dans la mesure où le calcul de redondance a disparu de l'en-tête IPv6.
 == Traitement des couches basses==

← Older revision		Revision as of 08:03, 24 May 2019
Line 1:		Line 1:
−
	__NOTOC__		__NOTOC__
	= Activité 24: Les mécanismes d’encapsulation =		= Activité 24: Les mécanismes d’encapsulation =

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Activité 24: Les mécanismes d’encapsulation  (Approfondissement)=
+= Activité 24: Les mécanismes d’encapsulation =
 {{Approfondissement}}
 ==Introduction==