WEBVTT 00:00.090 --> 00:01.050 Formateur : Dans cette 00:01.050 --> 00:04.200 leçon, nous allons présenter les concepts entourant l'IPv6, 00:04.200 --> 00:06.600 ou Protocole Internet version 6. 00:06.600 --> 00:07.740 Jusqu'à présent, 00:07.740 --> 00:10.230 nous n'avons parlé que de l'IPv4, mais 00:10.230 --> 00:13.020 l'un des problèmes de l'IPv4 est que son espace 00:13.020 --> 00:15.510 d'adressage est limité. 00:15.510 --> 00:17.370 En effet, l'adresse IPv4 ne 00:17.370 --> 00:19.380 comporte que 32 bits, ce qui nous 00:19.380 --> 00:23.070 en donne seulement 4. 2 milliards de combinaisons d'adresses possibles. 00:23.070 --> 00:26.430 Maintenant, j'en connais 4. 2 milliards, cela semble beaucoup d'adresses 00:26.430 --> 00:28.950 IP, mais lorsque nous avons supprimé des parties entières, 00:28.950 --> 00:32.160 comme les adresses APIPA, les adresses d'hôtes locaux, les adresses 00:32.160 --> 00:34.770 IP privées, et qu'il y a eu un énorme gaspillage avant même 00:34.770 --> 00:36.720 de commencer à utiliser le sous-réseau, cela 00:36.720 --> 00:38.670 a posé un gros problème et nous avons commencé 00:38.670 --> 00:42.810 à manquer d'adresses réseau dans le cadre de l'IPv4. 00:42.810 --> 00:46.860 C'est ce qu'on appelle l'épuisement de l'adresse, et c'est une réalité. 00:46.860 --> 00:49.260 En fait, en novembre 2019, le RIPE NCC, 00:49.260 --> 00:51.810 le registre Internet régional pour l'Europe, 00:51.810 --> 00:55.020 l'Asie de l'Ouest et l'ex-URSS, et la NASA ont déjà 00:55.020 --> 00:56.160 épuisé l'ensemble 00:56.160 --> 00:59.130 de leur réserve d'adresses IPv4. 00:59.130 --> 01:01.770 Heureusement, l'IETF (Internet Engineering 01:01.770 --> 01:04.740 Task Force) avait déjà commencé à se projeter 01:04.740 --> 01:06.600 dans l'avenir et a développé 01:06.600 --> 01:09.690 l'IPv6 en tant que norme dès 1995 avec une RFC qui 01:09.690 --> 01:13.380 documentait sa vision de l'IPv6, qu'elle appelait IP Next 01:13.380 --> 01:17.790 Generation ou IPNG (nouvelle génération d'IP). 01:17.790 --> 01:22.790 Vous voyez maintenant que l'IPv6 est en fait une énorme amélioration par rapport à l'IPv4 en 01:22.860 --> 01:25.290 termes de nombre d'adresses disponibles. 01:25.290 --> 01:28.710 Au lieu d'utiliser une adresse de 32 bits comme dans 01:28.710 --> 01:32.100 IPv4, IPv6 utilisera une adresse de 128 bits. 01:32.100 --> 01:35.490 Vous disposerez ainsi d'un espace d'adressage beaucoup plus important. 01:35.490 --> 01:37.620 En fait, il va vous donner une 01:37.620 --> 01:41.430 possibilité de 340 milliards d'adresses IP. 01:41.430 --> 01:42.930 Cela représente suffisamment d'adresses 01:42.930 --> 01:45.930 IP pour chaque homme, femme et enfant de la planète. 01:45.930 --> 01:48.540 Il s'agit de deux à la puissance 128. 01:48.540 --> 01:51.300 En fait, il y a beaucoup, beaucoup d'adresses IP pour chaque 01:51.300 --> 01:53.730 homme, femme et enfant de la planète parce qu'il 01:53.730 --> 01:56.250 y a tellement d'adresses IP disponibles. 01:56.250 --> 01:57.960 Vous vous demandez peut-être 01:57.960 --> 02:01.230 si nous sommes passés de l'IPv4 à l'IPv6. 02:01.230 --> 02:03.090 Qu'est-il advenu de la version 5 ? 02:03.090 --> 02:05.370 Pourquoi sommes-nous passés directement à la version 6 ? 02:05.370 --> 02:09.180 La version 5 a bien été créée, mais elle n'a jamais été pleinement adoptée en tant 02:09.180 --> 02:11.190 que protocole ou norme officielle. 02:11.190 --> 02:13.350 Il n'a donc jamais été produit. 02:13.350 --> 02:14.820 Au lieu de cela, un grand nombre de ces concepts 02:14.820 --> 02:16.350 développés dans le cadre de la version 5, 02:16.350 --> 02:17.970 parce qu'il s'agissait d'un protocole expérimental, 02:17.970 --> 02:19.920 ont été introduits dans l'IPv6 lorsqu'il est devenu 02:19.920 --> 02:21.870 une norme officielle. 02:21.870 --> 02:25.650 Parlons donc des avantages de l'IPv6. 02:25.650 --> 02:26.910 L'un des principaux avantages 02:26.910 --> 02:28.890 est que l'espace d'adressage est beaucoup 02:28.890 --> 02:31.350 plus vaste grâce à ces adresses de 128 bits. 02:31.350 --> 02:32.460 En outre, l'IPv6 a également 02:32.460 --> 02:35.160 amélioré l'efficacité de nos réseaux en supprimant 02:35.160 --> 02:38.730 le type de flux de données de diffusion de l'IPv4. 02:38.730 --> 02:41.250 Aujourd'hui, IPv6 est également plus sûr car 02:41.250 --> 02:44.010 il n'y a pas de fragmentation des paquets ou des datagrammes 02:44.010 --> 02:46.050 dans la norme IPv6. 02:46.050 --> 02:48.150 Il n'y a pas non plus d'unité de transmission 02:48.150 --> 02:51.330 maximale pour la découverte au sein de chaque session, contrairement 02:51.330 --> 02:54.870 à l'IPv4 qui contient un MTU d'une certaine taille pour chaque paquet. 02:54.870 --> 02:57.030 Avec IPv4, si je vous envoie un paquet dont la taille 02:57.030 --> 02:59.820 est supérieure à la taille maximale de l'unité de transmission, 02:59.820 --> 03:01.080 il sera fragmenté et envoyé 03:01.080 --> 03:02.400 sur le réseau. 03:02.400 --> 03:04.110 Une fois arrivé à destination, 03:04.110 --> 03:05.970 il est réassemblé et lu. 03:05.970 --> 03:07.650 Il s'agit en fait d'un risque pour la sécurité. 03:07.650 --> 03:09.540 Il nécessitait également un traitement supplémentaire 03:09.540 --> 03:11.460 et pouvait en fait ralentir vos réseaux parce qu'il 03:11.460 --> 03:13.920 devenait une manière très inefficace de faire les choses dans nos 03:13.920 --> 03:15.120 réseaux modernes avec des vitesses 03:15.120 --> 03:17.070 de connexion à l'internet plus élevées. 03:17.070 --> 03:19.830 Avec l'IPv6, ils ont donc décidé de supprimer 03:19.830 --> 03:21.900 complètement la fragmentation. 03:21.900 --> 03:24.480 Outre tous ces nouveaux avantages, les créateurs 03:24.480 --> 03:26.970 de l'IPv6 ont été très intelligents et ont 03:26.970 --> 03:30.690 compris que pour être pleinement adopté et accepté, l'IPv6 03:30.690 --> 03:33.630 devait être rétrocompatible avec l'IPv4 et permettre 03:33.630 --> 03:38.630 à l'IPv6 et à l'IPv4 de coexister sur le même réseau. 03:38.700 --> 03:41.490 Après tout, c'est déjà à la fin des années 1990 que l'IPv6 03:41.490 --> 03:43.950 a été développé et publié et que de nombreux réseaux 03:43.950 --> 03:45.270 informatiques ont été mis 03:45.270 --> 03:47.490 en place dans le monde entier. 03:47.490 --> 03:48.900 Il ne nous serait donc 03:48.900 --> 03:51.960 pas possible de tout changer en un seul jour. 03:51.960 --> 03:53.490 Pensez-y comme à la migration actuelle 03:53.490 --> 03:55.170 des véhicules à essence vers les véhicules 03:55.170 --> 03:56.730 électriques. 03:56.730 --> 03:58.920 Cela se produit tout au long des 03:58.920 --> 04:00.420 années 2020 et 2030. 04:00.420 --> 04:02.970 Il serait impossible de dire que le 1er janvier 04:02.970 --> 04:05.850 2025, plus personne ne pourra utiliser de véhicules 04:05.850 --> 04:07.710 à essence. 04:07.710 --> 04:08.700 Tous ces véhicules seront remplacés 04:08.700 --> 04:11.010 par des véhicules électriques à partir de cette date. 04:11.010 --> 04:12.180 Si un gouvernement essayait de 04:12.180 --> 04:14.160 faire cela, il aurait probablement une révolution 04:14.160 --> 04:17.190 sur les bras parce que beaucoup de gens possèdent déjà des voitures à essence et 04:17.190 --> 04:19.890 ont dépensé beaucoup d'argent et d'investissements dans ces voitures 04:19.890 --> 04:21.900 et dans l'infrastructure pour les supporter. 04:21.900 --> 04:24.480 C'est pourquoi nous n'allons pas simplement remplacer toutes les 04:24.480 --> 04:26.250 voitures à essence du jour au lendemain. 04:26.250 --> 04:28.680 Au lieu de cela, il y aura une lente transition de l'énergie 04:28.680 --> 04:32.130 gazeuse à l'énergie électrique d'ici 2030 ou peut-être 2040, car de plus en plus 04:32.130 --> 04:34.890 de voitures récentes vendues dans le monde le seront sous forme 04:34.890 --> 04:37.050 électrique et on cessera de vendre des véhicules 04:37.050 --> 04:39.390 fonctionnant à l'énergie gazeuse. 04:39.390 --> 04:42.900 C'est exactement la même chose avec l'IPv6. 04:42.900 --> 04:47.010 L'IPv6 permet donc à l'IPv4 et à l'IPv6 de coexister sur les mêmes réseaux 04:47.010 --> 04:49.140 et l'équipement qui fait fonctionner 04:49.140 --> 04:51.360 ces réseaux est connu sous le nom de double 04:51.360 --> 04:53.370 pile, ce qui signifie simplement qu'il 04:53.370 --> 04:54.930 peut faire fonctionner simultanément 04:54.930 --> 04:58.200 les protocoles IPv4 et les protocoles IPv6 sur les mêmes 04:58.200 --> 05:01.080 dispositifs de réseau. 05:01.080 --> 05:04.410 Avec les appareils à double pile, si un client prend en charge IPv6, le 05:04.410 --> 05:06.960 commutateur du routeur préférera utiliser IPv6 et communiquera 05:06.960 --> 05:08.760 selon cette méthode. 05:08.760 --> 05:11.370 Maintenant, si un appareil n'est pas en mesure de prendre 05:11.370 --> 05:13.080 en charge IPv6, il se retourne et dit, 05:13.080 --> 05:16.380 d'accord, je vais vous parler en utilisant l'ancien protocole IPv4. 05:16.380 --> 05:18.390 De cette façon, je peux encore vous soutenir. 05:18.390 --> 05:20.850 Une autre méthode que nous utilisons est connue sous le nom de tunneling. 05:20.850 --> 05:24.780 C'est ici que l'IPv6 sera tunnelé sur un dispositif IPv4. 05:24.780 --> 05:27.150 Cela permet à vos anciens routeurs IPv4 de 05:27.150 --> 05:29.580 continuer à acheminer le trafic IPv6. 05:29.580 --> 05:31.710 L'IPv6 sera essentiellement tunnelisé 05:31.710 --> 05:34.860 comme mécanisme d'encapsulation des paquets IPv6 dans 05:34.860 --> 05:38.370 les en-têtes IPv4 et de transport de ces données IPv6 par le biais 05:38.370 --> 05:40.320 des routeurs IPv4 et autres infrastructures 05:40.320 --> 05:42.480 existantes. 05:42.480 --> 05:44.640 Pour ce faire, il crée un tunnel point à point 05:44.640 --> 05:46.380 entre la source et la destination, 05:46.380 --> 05:48.450 puis encapsule ces informations. 05:48.450 --> 05:51.630 Cela permet à des clients et à des serveurs IPv6 isolés de communiquer 05:51.630 --> 05:53.310 sans avoir à mettre à niveau tous 05:53.310 --> 05:55.620 les routeurs et commutateurs qui utilisent 05:55.620 --> 05:59.040 encore IPv4 et qui peuvent exister entre eux. 05:59.040 --> 06:02.880 Aujourd'hui, il se peut qu'un jour, l'IPv4 soit complètement supprimé. 06:02.880 --> 06:05.070 Mais jusqu'à présent, cela ne s'est pas produit. 06:05.070 --> 06:07.440 Et personnellement, je ne retiens pas mon souffle. 06:07.440 --> 06:08.670 D'après certains articles 06:08.670 --> 06:11.160 que j'ai lus, l'IPv4 devrait rester en vigueur 06:11.160 --> 06:14.340 au moins jusqu'en 2040. En tant que technicien réseau, 06:14.340 --> 06:17.430 vous devrez donc savoir travailler avec l'IPv4 et 06:17.430 --> 06:20.640 l'IPv6 dans un avenir prévisible. 06:20.640 --> 06:24.120 Un autre avantage de l'IPv6 est qu'il dispose d'un en-tête simplifié. 06:24.120 --> 06:26.850 Ainsi, au lieu des 12 champs que nous avions dans IPv4, 06:26.850 --> 06:29.430 nous n'en avons plus que cinq dans IPv6, ce qui en 06:29.430 --> 06:30.960 fait un en-tête allégé beaucoup 06:30.960 --> 06:33.630 plus efficace à envoyer sur nos réseaux. 06:33.630 --> 06:35.370 Vous vous demandez peut-être 06:35.370 --> 06:37.920 à quoi ressemble un en-tête IPv6 ? 06:37.920 --> 06:40.500 Je vais vous le montrer, mais sachez que vous n'avez pas 06:40.500 --> 06:42.750 besoin de l'apprendre par cœur pour l'examen. 06:42.750 --> 06:44.940 Il s'agit plutôt de montrer les différents 06:44.940 --> 06:47.040 champs qui existaient dans IPv4, qui est en 06:47.040 --> 06:49.230 haut, par rapport à IPv6, qui est en bas. 06:49.230 --> 06:51.240 Vous pouvez maintenant constater 06:51.240 --> 06:54.450 à quel point IPv6 est plus simple qu'IPv4. 06:54.450 --> 06:56.190 Très bien, revenons à certains points 06:56.190 --> 06:58.170 que vous devez comprendre pour l'examen. 06:58.170 --> 07:01.590 Par exemple, à quoi ressemble une adresse IPv6 ? 07:01.590 --> 07:04.590 J'ai déjà dit qu'il avait une longueur de 128 bits, ce 07:04.590 --> 07:08.160 qui signifie qu'il y aurait 128 uns ou zéros si nous l'écrivions 07:08.160 --> 07:09.600 en binaire, et cela me semble 07:09.600 --> 07:11.910 être une très mauvaise idée, donc nous n'allons 07:11.910 --> 07:13.410 pas le faire. 07:13.410 --> 07:15.210 Nous pourrions utiliser la notation décimale 07:15.210 --> 07:16.680 pointée comme pour l'IPv4, mais 07:16.680 --> 07:19.020 cela représenterait encore beaucoup d'octets à écrire, 07:19.020 --> 07:23.670 car nous aurions besoin de 16 octets pour représenter l'ensemble des 128 bits. 07:23.670 --> 07:25.380 Pour résoudre ce problème, 07:25.380 --> 07:27.360 l'IETF a donc décidé d'utiliser 07:27.360 --> 07:29.310 des chiffres hexadécimaux. 07:29.310 --> 07:31.860 L'hexadécimal est en base 16, ce dont vous vous 07:31.860 --> 07:33.150 souvenez peut-être de 07:33.150 --> 07:34.980 vos cours d'algèbre au lycée. 07:34.980 --> 07:36.210 En hexadécimal, chaque chiffre 07:36.210 --> 07:38.760 hexadécimal représente en fait quatre bits. 07:38.760 --> 07:41.250 Cela va nous permettre de représenter une adresse IPv6 07:41.250 --> 07:43.710 en combinant quatre chiffres hexadécimaux pour former 07:43.710 --> 07:45.780 ce que nous appelons un segment. 07:45.780 --> 07:48.720 Un segment contient 16 bits. 07:48.720 --> 07:51.030 Elle est représentée par ces quatre chiffres hexadécimaux. 07:51.030 --> 07:52.440 Ensuite, nous ajouterons un deux-points 07:52.440 --> 07:53.880 et nous continuerons à ajouter des 07:53.880 --> 07:56.250 segments jusqu'à ce que nous atteignions 128 bits, ce qui 07:56.250 --> 07:57.900 nécessitera huit segments, chacun d'entre 07:57.900 --> 08:00.510 eux comportant quatre chiffres hexadécimaux. 08:00.510 --> 08:03.510 Cela me donne un total de 32 chiffres hexadécimaux, 08:03.510 --> 08:05.460 ce qui est encore assez long. 08:05.460 --> 08:09.330 Avec 128 bits représentés dans une adresse IPv6, cela signifie que 08:09.330 --> 08:12.810 nous n'aurons pas plus de 32 chiffres hexadécimaux à l'intérieur 08:12.810 --> 08:14.700 de tous ces segments. 08:14.700 --> 08:18.150 Pourquoi ai-je dit qu'il ne fallait pas dépasser 32 chiffres 08:18.150 --> 08:20.250 pour le total de ces huit segments ? 08:20.250 --> 08:22.800 Pourquoi ne serait-ce pas simplement 32 chiffres 08:22.800 --> 08:25.710 hexadécimaux, puisque 32 chiffres multipliés par quatre 08:25.710 --> 08:28.290 bits par chiffre donneraient 128 bits ? 08:28.290 --> 08:31.320 En effet, l'IPv6 nous permet d'utiliser une 08:31.320 --> 08:33.450 abréviation pour simplifier 08:33.450 --> 08:35.880 nos très longues adresses IPv6. 08:35.880 --> 08:37.980 Les règles de la sténographie sont très importantes 08:37.980 --> 08:40.650 car elles peuvent faire l'objet de questions d'examen. 08:40.650 --> 08:43.020 Ainsi, si vous avez quatre zéros pour un segment, 08:43.020 --> 08:45.360 vous pouvez en fait mettre un zéro à la place et 08:45.360 --> 08:47.310 supprimer les zéros initiaux. 08:47.310 --> 08:50.790 Par exemple, imaginons que j'aie une adresse IPv6 08:50.790 --> 08:55.790 très longue : 2018:0000:0000:0000:0000:0000:4815:54ae. 09:04.470 --> 09:05.820 En utilisant la règle simple, 09:05.820 --> 09:08.490 je peux remplacer tous les segments qui ont plusieurs 09:08.490 --> 09:09.810 zéros par un seul zéro. 09:09.810 --> 09:14.810 Cela me donnerait 2018:0:0:0:0:0:4815:54ae. 09:19.590 --> 09:22.680 Très bien, cela a permis de réduire le nombre de chiffres 09:22.680 --> 09:26.790 hexadécimaux de 32 à seulement 17, soit environ la moitié de la longueur. 09:26.790 --> 09:29.520 Nous nous améliorons, mais je ne vais pas m'arrêter là. 09:29.520 --> 09:30.710 Il existe une autre règle que 09:30.710 --> 09:33.000 je peux utiliser dans le monde de l'abréviation IPv6. 09:33.000 --> 09:35.280 Cette règle stipule que si plusieurs segments 09:35.280 --> 09:36.840 contiennent tous des zéros et qu'aucun 09:36.840 --> 09:39.420 autre chiffre hexadécimal n'y est représenté, je peux 09:39.420 --> 09:42.150 les résumer en utilisant un double deux-points et en supprimant 09:42.150 --> 09:44.160 tous ces zéros. 09:44.160 --> 09:45.420 Cette règle est particulière 09:45.420 --> 09:48.540 car on ne peut utiliser les deux points qu'une seule fois à l'intérieur 09:48.540 --> 09:50.460 d'une adresse IPv6. 09:50.460 --> 09:52.530 En utilisant ma règle des deux points, 09:52.530 --> 09:57.530 je peux donc résumer 2018:0:0:0:0:0:4815:54ae en supprimant ces cinq séries 10:00.750 --> 10:03.270 de zéros et en les remplaçant par un double 10:03.270 --> 10:07.450 point, ce qui me donne 2018::4815::54ae. 10:10.290 --> 10:13.020 Je suis donc passé de 32 chiffres hexadécimaux à 10:13.020 --> 10:14.910 17 chiffres hexadécimaux et maintenant 10:14.910 --> 10:17.160 je suis passé de 17 chiffres à 12 chiffres, 10:17.160 --> 10:19.080 ce qui est beaucoup plus petit et beaucoup 10:19.080 --> 10:21.690 plus facile à utiliser. 10:21.690 --> 10:24.240 Vous pouvez voir à quel point ce raccourci est utile. 10:24.240 --> 10:27.150 Comment reconnaître une adresse IPv6 10:27.150 --> 10:28.950 d'une adresse IPv4 ? 10:28.950 --> 10:32.130 La première façon consiste à examiner ce qu'est l'IPv4. 10:32.130 --> 10:35.400 L'IPv4 utilisera toujours la notation décimale pointée 10:35.400 --> 10:36.990 avec quatre octets. 10:36.990 --> 10:38.490 L'IPv6, quant à lui, utilise 10:38.490 --> 10:40.530 des deux-points entre les chiffres 10:40.530 --> 10:42.450 et s'écrit en hexadécimal. 10:42.450 --> 10:44.280 L'une des questions posées le 10:44.280 --> 10:45.810 jour du test consiste à identifier 10:45.810 --> 10:49.080 une adresse IPv6 lorsque vous en voyez une. 10:49.080 --> 10:51.180 Par exemple, on peut vous poser la question suivante 10:51.180 --> 10:53.700 : laquelle des adresses suivantes est une adresse IPv6 ? 10:53.700 --> 10:55.410 C'est une bonne question à vous poser. 10:55.410 --> 10:59.280 Vous allez avoir des options comme 192. 168. 1. 1, dont nous savons 10:59.280 --> 11:01.830 qu'il ne s'agit pas d'une adresse IPv4. 11:01.830 --> 11:06.830 Vous obtiendrez 12:34:56:78:90:AB 11:07.590 --> 11:12.000 ou 1234::5678::90AB. 11:12.000 --> 11:15.120 Attendez une minute, les deux dernières choses que je viens de dire sont 11:15.120 --> 11:17.010 vraiment similaires, n'est-ce pas ? 11:17.010 --> 11:20.310 Oui, mais une seule d'entre elles est une adresse IPv6 valide. 11:20.310 --> 11:21.630 Savez-vous de laquelle il s'agit ? 11:21.630 --> 11:24.000 Parce que la plupart des étudiants ne s'y retrouvent pas. 11:24.000 --> 11:28.020 La deuxième option n'est pas une adresse IPv6. 11:28.020 --> 11:29.820 Il s'agit plutôt d'une adresse MAC. 11:29.820 --> 11:31.260 N'oubliez pas que les adresses MAC, 11:31.260 --> 11:33.060 qui sont des adresses physiques de niveau 11:33.060 --> 11:35.580 2, sont toujours composées de 12 chiffres hexadécimaux 11:35.580 --> 11:37.230 séparés par des deux points. 11:37.230 --> 11:38.370 En général, ils sont écrits 11:38.370 --> 11:40.410 sous la forme de six groupes de deux chiffres chacun 11:40.410 --> 11:43.200 et chacun d'entre eux est séparé par un seul deux-points. 11:43.200 --> 11:46.080 Une adresse IPv6, en revanche, doit toujours être écrite en 11:46.080 --> 11:48.120 segments de quatre chiffres chacun, et elle 11:48.120 --> 11:50.580 doit toujours comporter 16 segments, à moins qu'il 11:50.580 --> 11:52.500 n'y ait un double deux-points. 11:52.500 --> 11:55.080 Dans cet exemple, nous avons un double deux-points entre 11:55.080 --> 11:58.020 le premier et le deuxième segment de notre troisième option. 11:58.020 --> 12:00.840 Il s'agit donc d'une bonne abréviation que nous pouvons utiliser 12:00.840 --> 12:03.450 et nous identifions qu'il s'agit d'une adresse IPv6 parce 12:03.450 --> 12:05.130 que nous avons supprimé tous les zéros 12:05.130 --> 12:08.520 entre le premier et le deuxième segment à l'intérieur de cette adresse. 12:08.520 --> 12:09.960 Ainsi, si vous comptez quelque 12:09.960 --> 12:11.790 chose qui ressemble à une adresse IPv6 12:11.790 --> 12:15.480 et qu'il y a 12, exactement 12 chiffres hexadécimaux séparés par des points 12:15.480 --> 12:17.040 simples, et que vous ne voyez pas 12:17.040 --> 12:18.840 de double point nulle part, il s'agit 12:18.840 --> 12:22.140 d'une adresse MAC, et non d'une adresse IPv6. 12:22.140 --> 12:24.180 Sinon, si elle ressemble à ceci et contient 12:24.180 --> 12:25.860 des chiffres hexadécimaux, il 12:25.860 --> 12:29.190 s'agira d'une adresse IPv6 le jour de l'examen. 12:29.190 --> 12:31.440 Pour l'examen, il suffit de savoir à quoi 12:31.440 --> 12:33.540 ressemble une adresse IPv6 et de pouvoir 12:33.540 --> 12:35.790 en résumer une en supprimant les zéros 12:35.790 --> 12:38.070 et en les consolidant à l'aide de l'astuce 12:38.070 --> 12:39.960 des deux points. 12:39.960 --> 12:41.490 Si vous pouvez faire ces deux choses, 12:41.490 --> 12:45.000 vous serez en mesure d'utiliser l'adressage IPv6 le jour de l'examen. 12:45.000 --> 12:47.280 En ce qui concerne l'adressage IPv6, il 12:47.280 --> 12:50.100 existe trois types d'adresses différents : les 12:50.100 --> 12:52.220 adresses unicast, les adresses multicast 12:52.220 --> 12:54.210 et les adresses anycast. 12:54.210 --> 12:56.640 L'un des aspects intéressants d'IPv6, qui 12:56.640 --> 12:59.040 le distingue réellement d'IPv4, est la possibilité 12:59.040 --> 13:01.830 d'attribuer plusieurs adresses IPv6 à une seule 13:01.830 --> 13:03.900 interface d'un client. 13:03.900 --> 13:05.730 Ces attributions peuvent être 13:05.730 --> 13:07.680 un mélange de ces trois types différents 13:07.680 --> 13:10.290 : unicast, multicast et anycast. 13:10.290 --> 13:13.140 Ainsi, même si vous n'avez qu'une seule carte d'interface 13:13.140 --> 13:14.910 réseau sur votre station de travail 13:14.910 --> 13:17.430 ou votre ordinateur portable, vous pouvez avoir plusieurs 13:17.430 --> 13:19.860 adresses IPv6 et différents types d'adresses IPv6 13:19.860 --> 13:22.140 attribués à cette seule carte. 13:22.140 --> 13:23.850 Les adresses de monodiffusion seront utilisées 13:23.850 --> 13:25.950 pour identifier une seule interface. 13:25.950 --> 13:28.950 Celles-ci sont divisées en adresses unicast acheminées globalement 13:28.950 --> 13:30.930 et en adresses link-local. 13:30.930 --> 13:32.760 Une adresse de monodiffusion acheminée 13:32.760 --> 13:36.150 à l'échelle mondiale est similaire à ce que nous avons comme adresse publique 13:36.150 --> 13:39.600 avec IPv4 en utilisant des adresses de monodiffusion de classe A, B et C. 13:39.600 --> 13:42.840 Dans l'IPv6, une adresse unicast à acheminement 13:42.840 --> 13:44.220 global commencera 13:44.220 --> 13:49.050 toujours par un premier segment contenant 2000-3999. 13:49.050 --> 13:52.740 Si le premier segment est 2000-3999, cela signifie qu'il s'agit d'une 13:52.740 --> 13:55.770 adresse de monodiffusion à acheminement global. 13:55.770 --> 13:58.050 Par exemple, l'adresse IPv6 13:58.050 --> 14:03.050 2584:0db8:8583:1234:5678:882e:0370:7334 serait acheminée 14:10.800 --> 14:14.010 globalement en tant qu'adresse unicast 14:14.010 --> 14:17.070 parce que son premier segment contient 14:17.070 --> 14:20.670 2584, qui se situe entre 2000 et 3999. 14:20.670 --> 14:22.650 En revanche, une adresse locale de liaison, 14:22.650 --> 14:24.690 également appelée adresse d'utilisation locale, 14:24.690 --> 14:28.020 est utilisée de la même manière qu'une adresse IP privée dans IPv4. 14:28.020 --> 14:29.970 Une adresse locale en IPv6 14:29.970 --> 14:32.097 ne peut être utilisée que sur 14:32.097 --> 14:36.840 un réseau local et commence toujours par FE80 comme premier segment 14:36.840 --> 14:38.940 d'une adresse IPv6. 14:38.940 --> 14:41.760 Désormais, lorsqu'un système IPv6 démarre, il va créer 14:41.760 --> 14:44.100 une adresse locale pour chaque interface IPv6 14:44.100 --> 14:47.070 de ce système, même si une adresse routable au niveau mondial 14:47.070 --> 14:48.720 a déjà été configurée manuellement 14:48.720 --> 14:50.190 ou obtenue par le biais d'un 14:50.190 --> 14:53.700 protocole de configuration tel que DHCP. 14:53.700 --> 14:56.340 Pour ce faire, il va utiliser ce que l'on appelle 14:56.340 --> 15:00.840 le SLAAC, l'auto-configuration d'adresse sans état ou S-L-A-A-C. 15:00.840 --> 15:02.610 Avec l'auto-configuration sans état, 15:02.610 --> 15:04.680 l'hôte n'a pas besoin d'obtenir des adresses 15:04.680 --> 15:06.210 ou d'autres informations de configuration 15:06.210 --> 15:08.880 auprès d'un serveur centralisé comme DHCP. 15:08.880 --> 15:11.640 Au lieu de cela, il peut en fait s'attribuer indépendamment 15:11.640 --> 15:13.050 une adresse locale de liaison, 15:13.050 --> 15:15.420 tester l'unicité de cette adresse locale de liaison, 15:15.420 --> 15:17.430 s'attribuer l'adresse locale de liaison, 15:17.430 --> 15:20.220 contacter le routeur et indiquer au nœud comment procéder 15:20.220 --> 15:22.680 à l'auto-configuration. 15:22.680 --> 15:25.770 Il peut même configurer l'adresse de monodiffusion globale qu'il 15:25.770 --> 15:27.090 souhaite utiliser. 15:27.090 --> 15:29.520 Nous reviendrons sur ce concept dans quelques 15:29.520 --> 15:31.110 minutes, lorsque nous commencerons 15:31.110 --> 15:34.080 à parler de l'EUI-64 et du protocole de découverte des voisins, 15:34.080 --> 15:35.580 car ces deux processus sont utilisés 15:35.580 --> 15:37.650 avec le protocole d'autoconfiguration 15:37.650 --> 15:41.580 d'adresses sans état, connu sous le nom de SLAAC. 15:41.580 --> 15:43.680 Ensuite, nous avons les adresses de multidiffusion. 15:43.680 --> 15:45.360 Les adresses de multidiffusion sont utilisées 15:45.360 --> 15:47.100 pour identifier un groupe d'interfaces 15:47.100 --> 15:49.710 afin qu'un paquet puisse être envoyé à une adresse de multidiffusion 15:49.710 --> 15:52.680 et distribué à toutes les interfaces du groupe. 15:52.680 --> 15:56.550 Dans l'IPv6, une adresse de multidiffusion contiendra toujours FF comme 15:56.550 --> 15:59.460 les deux premiers chiffres du premier segment. 15:59.460 --> 16:02.280 Si vous voyez FF au début d'une adresse IPv6, rappelez-vous 16:02.280 --> 16:04.800 qu'il s'agit d'une adresse multicast. 16:04.800 --> 16:06.330 Le dernier type d'adresse dont nous 16:06.330 --> 16:08.700 disposons est connu sous le nom d'adresse anycast. 16:08.700 --> 16:11.610 Les adresses Anycast sont utilisées pour identifier un ensemble d'interfaces afin 16:11.610 --> 16:14.400 qu'un paquet puisse être envoyé à n'importe quel membre de cet ensemble. 16:14.400 --> 16:16.320 Les adresses Anycast sont en fait attribuées à 16:16.320 --> 16:18.060 partir de l'espace d'adressage unicast. 16:18.060 --> 16:19.620 Il n'y a donc aucun moyen de 16:19.620 --> 16:22.710 déterminer si une adresse IPv6 est unicast ou anycast 16:22.710 --> 16:25.410 simplement en regardant l'adresse IPv6. 16:25.410 --> 16:28.050 Si l'on considère le multicast ou le link-local, on dispose d'un 16:28.050 --> 16:29.790 moyen très simple de le faire, mais on ne dispose 16:29.790 --> 16:31.440 pas d'un moyen simple de déterminer si 16:31.440 --> 16:33.870 l'on est en présence d'unicast ou d'anycast. 16:33.870 --> 16:35.010 Très bien, revenons en 16:35.010 --> 16:36.990 arrière et parlons un peu plus de SLAAC, 16:36.990 --> 16:40.140 le processus d'auto-configuration d'adresses sans état. 16:40.140 --> 16:42.090 Comme je l'ai dit, l'IPv6 dispose d'un processus 16:42.090 --> 16:45.120 d'auto-configuration connu sous le nom de SLAAC, que nous utilisons 16:45.120 --> 16:46.980 pour découvrir le réseau actuel sur lequel 16:46.980 --> 16:48.570 se trouve l'interface, puis pour 16:48.570 --> 16:51.360 lui permettre de sélectionner son propre identifiant d'hôte 16:51.360 --> 16:56.360 sur la base de son adresse MAC à l'aide d'un processus connu sous le nom d'EUI-64. 16:56.550 --> 17:01.410 Ce processus EUI-64 (Extended Unique Identifier) permettra à un 17:01.410 --> 17:03.450 hôte de s'attribuer un identifiant 17:03.450 --> 17:07.967 d'interface IPv6 unique de 64 bits appelé EUI-64. 17:09.180 --> 17:12.000 Cette adresse au format EUI-64 est obtenue en 17:12.000 --> 17:15.480 utilisant l'adresse MAC de 48 bits de l'interface. 17:15.480 --> 17:19.260 L'adresse MAC est d'abord séparée en deux parties de 24 bits. 17:19.260 --> 17:22.890 La première moitié de l'adresse MAC contient l'OUI (Organizational 17:22.890 --> 17:25.170 Unique Identifier). 17:25.170 --> 17:26.850 La seconde moitié contiendra la 17:26.850 --> 17:29.010 carte d'interface réseau spécifique. 17:29.010 --> 17:30.780 Entre les deux, nous allons 17:30.780 --> 17:35.730 insérer une valeur hexadécimale de 16 bits, FFFE. 17:35.730 --> 17:39.990 Ainsi, je peux prendre 24 bits, 16 bits et 24 bits et 17:39.990 --> 17:44.760 les assembler pour obtenir une adresse EUI de 64 bits. 17:44.760 --> 17:47.340 Cela vous donne les 64 bits dont vous aurez besoin 17:47.340 --> 17:49.860 pour identifier votre interface sur ce réseau. 17:49.860 --> 17:52.320 Ensuite, l'interface utilisera la découverte 17:52.320 --> 17:53.910 automatique pour déterminer 17:53.910 --> 17:57.030 le réseau sur lequel elle se trouve et ajoutera la partie réseau 17:57.030 --> 18:00.960 de l'adresse IPv6, qui sera les 64 premiers bits de nos adresses. 18:00.960 --> 18:02.940 Nous allons maintenant placer les 64 premiers 18:02.940 --> 18:05.580 bits représentant le réseau devant les 64 bits de l'adresse 18:05.580 --> 18:09.390 EUI-64 que nous avons créée à partir de notre adresse MAC afin de créer une adresse 18:09.390 --> 18:14.550 IPv6 unicast routable à l'échelle mondiale que nous pouvons maintenant utiliser. 18:14.550 --> 18:16.890 Vous pouvez donc voir comment tout cela fonctionne ensemble 18:16.890 --> 18:18.180 en utilisant cette adresse MAC 18:18.180 --> 18:20.700 pour créer cette adresse routable au niveau mondial. 18:20.700 --> 18:24.180 Aujourd'hui, le DHCP peut également être utilisé dans le cadre de l'IPv6 si 18:24.180 --> 18:25.560 vous préférez l'utiliser. 18:25.560 --> 18:29.520 Si c'est le cas, vous devrez utiliser le protocole DHCPv6. 18:29.520 --> 18:30.930 Cela vous permettrait de faire en 18:30.930 --> 18:34.650 sorte que DHCP attribue automatiquement des éléments à partir d'un serveur DHCPv6. 18:34.650 --> 18:38.520 Mais comme le processus d'auto-configuration avec EUI-64 est déjà intégré 18:38.520 --> 18:41.430 par défaut dans le protocole IPv6, il n'est pas vraiment 18:41.430 --> 18:43.230 nécessaire d'utiliser DHCPv6. 18:44.280 --> 18:47.580 Mais si vous voulez utiliser DHCPv6, vous pouvez le faire, et cela 18:47.580 --> 18:48.870 vous permettra d'assigner 18:48.870 --> 18:51.360 les adresses que chaque interface recevra au lieu 18:51.360 --> 18:52.500 de les laisser utiliser 18:52.500 --> 18:55.170 le protocole d'auto-configuration de SLAAC. 18:55.170 --> 18:58.560 Comme je l'ai dit, l'IPv6 choisit par défaut sa propre adresse 18:58.560 --> 19:00.930 sur la base de son adresse MAC, puis il utilise 19:00.930 --> 19:03.480 le protocole de découverte des voisins (NDP) 19:03.480 --> 19:05.310 pour connaître les autres adresses 19:05.310 --> 19:08.370 de la couche 2 du réseau sur la base de leur adresse MAC, 19:08.370 --> 19:09.990 puis il choisit son propre identifiant 19:09.990 --> 19:12.630 d'hôte. 19:12.630 --> 19:15.630 Pour l'examen, vous n'avez pas besoin de connaître NDP en profondeur, 19:15.630 --> 19:17.850 mais vous devez comprendre que NDP, ce protocole de 19:17.850 --> 19:20.847 découverte du voisin, est utilisé dans IPv6 et qu'il reprend une grande 19:20.847 --> 19:22.410 partie des fonctions de l'annonce du 19:22.410 --> 19:24.420 routeur et de la découverte du voisin et qu'il les 19:24.420 --> 19:25.683 gère pour vous.