|
|
| (20 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | > [[MOOC:Accueil|MOOC]]>[[MOOC:Ebauche_Contenu|Contenu]]>[[MOOC:Sequence_2|Sequence 2]]
| |
| − | ----
| |
| − | = L'intégration d'IPv6 dans la pile des protocoles =
| |
| | | | |
| − | == 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
| |
| − |
| |
| − | Autres Ressources
| |
| − | * http://livre.g6.asso.fr/index.php?title=Checksum_au_niveau_transport
| |
| − | * http://livre.g6.asso.fr/index.php?title=Format_du_paquet_IPv6
| |
| − | * http://livre.g6.asso.fr/index.php?title=Pseudo-en-t%C3%AAte
| |
| − |
| |
| − | == Vidéo ==
| |
| − | [http://rainet.telecom-lille.fr/telechargement/morelle/A22_IPv6.mp4 Maquette]
| |
| − |
| |
| − | 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
| |
| − |
| |
| − | == [[MOOC:Compagnon_Act22|Texte de référence]]==
| |
| − |
| |
| − | chapitre Document Compagnon
| |
| − |
| |
| − | Textes pouvant servir de référence
| |
| − | * http://deptinfo.cnam.fr/Enseignement/Memoires/LUSTEAU.Franck/Pages/Les_codages.htm
| |
| − | * http://fr.wikipedia.org/wiki/Contr%C3%B4le_de_redondance_cyclique
| |
| − | * http://fr.wikipedia.org/wiki/Point-to-Point_Protocol
| |
| − | * http://fr.wikipedia.org/wiki/Asynchronous_Transfer_Mode
| |
| − | * http://fr.wikipedia.org/wiki/Ethernet
| |
| − | * https://fr.wikipedia.org/wiki/6LoWPAN
| |
| − |
| |
| − | Le Wiki du G6
| |
| − | * http://livre.g6.asso.fr/index.php?title=Format_du_paquet_IPv6
| |
| − |
| |
| − | == Quizz ==
| |
| − | 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)
| |
| − |
| |
| − |
| |
| − | <quiz display=simple>
| |
| − |
| |
| − | {Quel impact a le temps de calcul du CRC au niveau 2 ?
| |
| − | |type="[]"}
| |
| − | - énorme, cela augmente la latence de la transmission
| |
| − | + Aucun c'est le coupleur qui le fait à la volée
| |
| − | - Aucune importance, les routeurs corrigent les CRC à la volée
| |
| − | - Ce calcul est optionnel, et n'est que rarement employé de nos jours
| |
| − |
| |
| − |
| |
| − | {Est ce que le CRC de niveau 2 est l'arme absolue pour la détection des erreurs ?
| |
| − | |type="[]"}
| |
| − | - Oui, sinon inutile de l'inclure à tous les niveaux
| |
| − | + Non, il est nécessaire de contrôler l'intégrité au niveau supérieur
| |
| − | - peu importe, l'application corrige
| |
| − | - IPv6 intègre la correction d'erreur
| |
| − |
| |
| − | {La taille de la MTU de niveau 2 ?
| |
| − | |type="[]"}
| |
| − | + d'au moins 1280 octets est fortement conseillée
| |
| − | - peu importe la taille maximum, la fragmentation est intégrée d'emblée
| |
| − | - est désormais adaptative dans les systèmes ayant le label IPv6 Ready
| |
| − | - doit être absolument identique sur tout le parcours des paquets
| |
| − |
| |
| − |
| |
| − | {Le temps de calcul du CRC de niveau 2 et supérieur impacte il le délai des échanges ?
| |
| − | |type="[]"}
| |
| − | - Oui, d'autant plus que ce calcul est fait à différents niveaux
| |
| − | - Oui, car ce calcul est réalisé dans les couches intermédiaires
| |
| − | + Non car de nombreux coupleurs décharge les couches de protocoles de ce calcul
| |
| − | - ce calcul étant optionnel, aucun impact notoire n'est constaté
| |
| − |
| |
| − |
| |
| − |
| |
| − | {Au niveau 4, les couches transport UDP et TCP ...
| |
| − | |type="[]"}
| |
| − | + intègrent l'entête IPv6 dans le calcul d'intégrité du CRC
| |
| − | - combinent n° de port, numéro de séquence et accusé de réception
| |
| − | - s'adaptent dynamiquement aux besoins applicatifs
| |
| − | - sont prises en compte par les routeurs de transit
| |
| − |
| |
| − | </quiz>
| |
| − |
| |
| − | === Explications : ===
| |
| − | *1 Le calcul du CRC est réalisé au niveau 2 par un circuit ASIC du coupleur, ce traitement se fait à la volée, et aucun ralentissement n'est notoire. De plus de nombreux coupleurs récents proposent de décharger les couches de niveau 3 et 4. Ce qui permet d'accélérer ces calculs et donc d'optimiser la consommation CPU des systèmes d'exploitation.
| |
| − |
| |
| − | *2 Le calcul de CRC au niveau 2 permet d'écarter des trames qui auraient subies des perturbations pendant le trajet sur les supports physiques, mais ceci n'est pas suffisant, car on peut aisément imaginer que si un ou plusieurs paquets ont été perdus au cours du trajet, seules les couches supérieures seront à même de réaliser les traitements nécessaires à la détection des paquets non acheminés. Si le calcul de CRC n'est pas présent au niveau 3, il est nécessaire au niveau 4, on considère que la couche application récupère un flux fiable au delà du niveau transport.
| |
| − |
| |
| − | *3 Une taille de MTU de 1280 est fortement conseillée, car le mécanisme de fragmentation n'est pas déclenché systématiquement. La taille de MTU peut être différente sur chaque liaison intermédiaire.Aucun label IPv6 ready n'a été mis en place pour l'instant.
| |
| − |
| |
| − | *4 Le calcul du CRC est réalisé au niveau 2 par un circuit ASIC du coupleur, ce traitement se fait à la volée, et aucun ralentissement n'est notoire. De plus de nombreux coupleurs récents proposent de décharger les couches de niveau 3 et 4. Ce qui permet d'accélérer ces calculs et donc d'optimiser la consommation CPU des systèmes d'exploitation.
| |
| − |
| |
| − | *5 Les couches de tranport intègrent l'en-tête IPv6 dans le calcul du CRC de niveau 4. Ceci assurent une indépendance des applications et simplifient le traitement des routeurs sur le trajet emprunté dans le réseau.
| |
| − |
| |
| − | == Exercices ==
| |
| − |
| |
| − | [[File:2015_10_13_A22_03_pcap.jpg|600px|thumb|center|Datagramme IPv6 A22_03]]
| |
| − |
| |
| − |
| |
| − | Sur cette capture d'écran wireshark, nous observons un paquet IPv6
| |
| − | S'agit-il d'une trame ethernet broadcast, multicast, ou unicast ?
| |
| − | Pourquoi aucun champ CRC n'est affiché dans le décodage détaillé du niveau 2 ?
| |
| − | Comment se fait-il que la longueur de cette trame Ethernet puisse être de 62 Octets ? Ne manquerai t'il pas quelque chose ?
| |
| − |
| |
| − | Quelle est la longueur de l'en-tête IPv6
| |
| − | A quoi correspond l'adresse IPv6 ff02::2 ?
| |
| − |
| |
| − | Quel est l'intérêt d'un champ Checksum dans ICMPv6 ?
| |
