Difference between revisions of "MOOC:Activité 24"

From Livre IPv6

(→‎Slides)
(→‎Objectifs pédagogiques)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]]>[[MOOC:Sequence_2|Sequence 2]]
 
> [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]]>[[MOOC:Sequence_2|Sequence 2]]
 
----
 
----
−
= Nouvelles fonctionnalités de l'entête IPv6 =
+
= Les mécanismes d’encapsulation =
  
−
Principe d'extension : Adapter le niveau IP à de nouvelles fonctionnalités
+
== Objectifs pédagogiques ==
−
* Exemple de fonctionnalités
+
−
** Extension de routage / Mobilité
+
−
** La sécurité
+
  
−
* Next Header
 
−
* Quelques exemples de fonctionnalités
 
−
** Extension de routage / Mobilité
 
−
** Extension de fragmenntation
 
−
** Extension d'authentification
 
−
* Ressources supplémentaires
 
  
 +
* Traitement dans les couches basses
 +
** Couche physique
 +
** Couche liaison
 +
* Couches intermédiaires
 +
** Couche réseau
 +
** Couche transport
 +
** UDP-Lite
 +
** Rôle du checksum
  
−
== Objectifs pédagogiques ==
 
  
 +
Comprendre l'encapsulation dans les protocoles de niveau 2
  
−
== Vidéo ==
+
Le Niveau 2 permet d'identifier gràce aux blocs nommées trames, les séquences de codages utiles au transport d'information ou de protocole de signalisation, du reste nécessaire à la synchronisation du dialogue entre équipements connectés:
−
Petit scénario pour une vidéo de 5 min maximum
+
* délimitation d'une trame Ethernet (asynchrone sur cuivre ou synchrone sur FO)
  
−
== Slides ==
+
Comprendre pourquoi le checksum a été enlevé de la couche IP:
  
−
* Entête IPv6 description du champ Next Header
+
actuellement les protocoles de niveau 2 disposent d'un fonction CRC, permettant d'ignorer les trames incorrectes.
−
* imbrication des extensions dans l'encapsulation
+
Un champ CRC était inclus dans IPv4 car à l'origine les transmissions sur ligne téléphonique étaient réalisées avec des modems sans dispositif de détection/correction d'erreurs (cas du protocole SLIP)
−
* exemple extension du routage à la source / mobilité
+
−
* conséquence sur le traitement des extensions par les piles de protocoles
+
−
* intérêt des extension pour la sécurité
+
−
* exemple AH  & ESP
+
  
−
http://eurekom.fr/ftp/Mooc_IPv6/24_Mooc-IPv6.pdf
 
  
−
== [[MOOC:Compagnon_Act24|Texte de référence]]==
+
Lien avec les protocoles de niveau 4  (Trouver le fil conducteur: CRC )
−
Chapitre Document Compagnon
+
* Checksum / Pseudo-entête
 +
* UDP-Lite
  
−
Textes pouvant servir de référence
+
-------------
  
−
* http://livre.g6.asso.fr/index.php?title=IPv6_QO
+
Présentation de
 +
- l'encapsulation dans les protocoles de niveau 2
 +
- le rôle du checksum
 +
- expliquer l'abs de checksum dans IPv6
 +
- l'encapsulation dans le paquet IPv6, Lien avec les protocoles de niveau 4  (Trouver le fil conducteur: CRC )
 +
* Checksum / Pseudo-entête
 +
* UDP-Lite
  
−
*http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
+
Le Niveau 2 permet d'identifier gràce aux blocs nommées trames, les séquences de codages utiles au transport d'information ou de protocole de signalisation, du reste nécessaire à la synchronisation du dialogue entre équipements connectés:
  
−
== Quizz ==
+
actuellement les protocoles de niveau 2 disposent d'un fonction CRC, permettant d'ignorer les trames incorrectes.
−
il peut y avoir 1, 2, 3 ou 4 bonnes réponses, si une seule mauvaise est cochée, elle annule la (ou les) bonne(s)  réponse(s)
+
Un champ CRC était inclus dans IPv4 car à l'origine les transmissions sur ligne téléphonique étaient réalisées avec des modems sans dispositif de détection/correction d'erreurs (cas du protocole SLIP)
  
 +
== Vidéo ==
  
−
<quiz display=simple>
+
Petit scénario pour une vidéo de 5 min maximum:
  
−
{Le mécanisme d’extension IPv6
+
* décrire la synchronisation niveau 1
−
|type="[]"}
+
* auto négociation débit & duplex
−
- Est optionnel et peut alourdir le traitement des routeurs intermédiaires
+
* séparation du codage nécessaire à la synchro (symboles idle)  du flux utile à la reconnaissance du début de trame, fin de trame
−
- Apporte une grande diversité de traitement aux machines concernées
+
* extraction et vérification du CRC
−
- Bouscule le format des paquets IPv6, et par conséquent complique leur acheminement
+
* exploitation de l'entête : broadcast, multicast, unicast
−
+ Est identifié par le contenu champ Next Header
+
* interprétation des champs type/longueur/vlan/cos/
 +
* décapsulation du contenu des trames, remise du paquet à la couche supérieure
 +
* tri de courrier ou de cartons sur un tapis roulant: cartons de couleur correspondant au trafic utile
 +
cartons gris au bourrage, vérification de l'intégrité du carton (pas de trace de chocs) analogie avec CRC
 +
lecture code barre / étiquette / adresses, déballage du carton pour extraire un autre carton, ou enveloppe avec d'autres champs et des adresses de niveau 3..., je commande un tapis roulant de déménageur chez kiloutou ?
 +
prix, délai ...
 +
 
 +
== Slides ==
  
 +
Encapsulation générique Trame/Paquet/Segment/Data
  
−
{Le  champ Next Header permet
+
Décider si on présente la descente (envoi des paquets) dans les couches ou la remontée (réception des paquets) ?
−
|type="[]"}
+
−
+ Indique le protocole encapsulé dans IPv6
+
−
+ Détermine si un mécanisme d’extension est inclus dans le paquet IPv6
+
−
- N’est pas renseigné dans le cas des tunnels
+
−
- Indique la longueur de l’extension si elle est présente
+
  
−
{Les extensions impliquent
+
Encapsulation de niveau 2
−
|type="[]"}
+
Ethernet vs ATM vs PPP
−
- Un traitement nécessaire par les extrémités, dans le cas extension de type destinataire
+
−
- Un traitement de tous les routeurs intermédiaires, dans tous les cas
+
−
+ Le traitement des routeurs intermédiaires désignés, avec l’extension RH0
+
−
- Le changement d’adresses dans le cadre de la mobilité IPv6 
+
  
−
{Le mécanisme d’extension   
+
focus sur la l'identification du temps de parole grâce au codage / tramage
−
|type="[]"}
+
−
- Nécessite un champ Next header à longueur variable
+
−
+ Permet le chainage des extensions en utilisant au début de l’extension autant de champ Next Header que d’extensions chainées
+
−
- Est limité à 3 extensions successives
+
−
- Complique la fragmentation des paquets IPv6 
+
−
+
−
{Le mécanisme d’extension de routage de type 0
+
−
|type="[]"}
+
−
+ Permet de modifier la route de tous les paquets d’un flux origine destination
+
−
+ Permet d’identifier les routeurs désignés intermédiaires
+
−
- Doit être traités par tous les routeurs intermédiaires désignés et non désignés
+
−
- Limite la valeur du champ TTL à 6, donc le nombre de routeurs intermédiaires est également contraint
+
  
−
</quiz>
+
focus sur le CRC : dispositif de protection fiable
  
−
=== Explications  ===
+
identification rapide des champs @mac, type/longueur
−
*1 Le mécanisme d'extension est bien identifié par le champ Next Header, seul les équipements concernés, extrémités ou routeurs désignés seront impactés.
+
  
−
*2 Le champ Next Header indique bien quel protocole est encapsulé dans IPv6, ou bien quel mécanisme d'extension est inclus. Pour découvrir la longueur de l'extension il faut décoder le champ Header Extension Lenght qui sera présenté en début du codage de l'extension.
+
introduction du MTU, adaptation du MTU aux interfaces réseaux de niveau 2
  
−
*3 Les extensions impliquent le traitement des routeurs intermédiaires désignés, avec l’extension RH0. Sinon cela ne concerne que l'extrémité dans le cas extension de type destinataire. Les routeurs intermédiaires ne sont pas impactés. Un changement d'adresse n'est pas systématique dans le cadre de la mobilité IPv6.
+
impasse sur LLC / SNAP (visible uniquement sur accès xDSL PPPoA)
  
−
*4 Le mécanisme d’extension permet le chainage des extensions en utilisant au début de l’extension autant de champ Next Header que nécessaire. Cela ne complique pas plus que cela la fragmentation.
+
Intérêt du CRC de niveau Transport : UDP/TCP
 +
capable de detecter des erreurs sur les adresses des paquets IPv6
  
−
*5 Le mécanisme d’extension de routage de type 0 permet bien de modifier la route d'un flux orgine/destination, ainsi que d'identifier les routeurs désignés intermédiaires, puisque l'on retrouve leur liste dans l'extension. Les routeurs intermédiaires non désignés ne sont pas impactés .
 
  
−
== Exercices ==
+
http://eurekom.fr/ftp/Mooc_IPv6/22_Mooc-IPv6.pdf

Latest revision as of 04:31, 30 April 2019

> MOOC>Contenu>Sequence 2

Les mécanismes d’encapsulation

Objectifs pédagogiques

  • Traitement dans les couches basses
    • Couche physique
    • Couche liaison
  • Couches intermédiaires
    • Couche réseau
    • Couche transport
    • UDP-Lite
    • Rôle du checksum


Comprendre l'encapsulation dans les protocoles de niveau 2

Le Niveau 2 permet d'identifier gràce aux blocs nommées trames, les séquences de codages utiles au transport d'information ou de protocole de signalisation, du reste nécessaire à la synchronisation du dialogue entre équipements connectés:

  • délimitation d'une trame Ethernet (asynchrone sur cuivre ou synchrone sur FO)

Comprendre pourquoi le checksum a été enlevé de la couche IP:

actuellement les protocoles de niveau 2 disposent d'un fonction CRC, permettant d'ignorer les trames incorrectes. Un champ CRC était inclus dans IPv4 car à l'origine les transmissions sur ligne téléphonique étaient réalisées avec des modems sans dispositif de détection/correction d'erreurs (cas du protocole SLIP)


Lien avec les protocoles de niveau 4 (Trouver le fil conducteur: CRC )

  • Checksum / Pseudo-entête
  • UDP-Lite

Présentation de - l'encapsulation dans les protocoles de niveau 2 - le rôle du checksum - expliquer l'abs de checksum dans IPv6 - l'encapsulation dans le paquet IPv6, Lien avec les protocoles de niveau 4 (Trouver le fil conducteur: CRC )

  • Checksum / Pseudo-entête
  • UDP-Lite

Le Niveau 2 permet d'identifier gràce aux blocs nommées trames, les séquences de codages utiles au transport d'information ou de protocole de signalisation, du reste nécessaire à la synchronisation du dialogue entre équipements connectés:

actuellement les protocoles de niveau 2 disposent d'un fonction CRC, permettant d'ignorer les trames incorrectes. Un champ CRC était inclus dans IPv4 car à l'origine les transmissions sur ligne téléphonique étaient réalisées avec des modems sans dispositif de détection/correction d'erreurs (cas du protocole SLIP)

Vidéo

Petit scénario pour une vidéo de 5 min maximum:

  • décrire la synchronisation niveau 1
  • auto négociation débit & duplex
  • séparation du codage nécessaire à la synchro (symboles idle) du flux utile à la reconnaissance du début de trame, fin de trame
  • extraction et vérification du CRC
  • exploitation de l'entête : broadcast, multicast, unicast
  • interprétation des champs type/longueur/vlan/cos/
  • décapsulation du contenu des trames, remise du paquet à la couche supérieure
  • tri de courrier ou de cartons sur un tapis roulant: cartons de couleur correspondant au trafic utile

cartons gris au bourrage, vérification de l'intégrité du carton (pas de trace de chocs) analogie avec CRC lecture code barre / étiquette / adresses, déballage du carton pour extraire un autre carton, ou enveloppe avec d'autres champs et des adresses de niveau 3..., je commande un tapis roulant de déménageur chez kiloutou ? prix, délai ...

Slides

Encapsulation générique Trame/Paquet/Segment/Data

Décider si on présente la descente (envoi des paquets) dans les couches ou la remontée (réception des paquets) ?

Encapsulation de niveau 2 Ethernet vs ATM vs PPP

focus sur la l'identification du temps de parole grâce au codage / tramage

focus sur le CRC : dispositif de protection fiable

identification rapide des champs @mac, type/longueur

introduction du MTU, adaptation du MTU aux interfaces réseaux de niveau 2

impasse sur LLC / SNAP (visible uniquement sur accès xDSL PPPoA)

Intérêt du CRC de niveau Transport : UDP/TCP capable de detecter des erreurs sur les adresses des paquets IPv6


http://eurekom.fr/ftp/Mooc_IPv6/22_Mooc-IPv6.pdf

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Activité_24&oldid=15534"
Personal tools