WEBVTT 00:00.090 --> 00:01.050 Instructeur: In 00:01.050 --> 00:04.200 deze les gaan we de concepten rond IPv6, of Internet 00:04.200 --> 00:06.600 Protocol versie 6, introduceren. 00:06.600 --> 00:07.740 Tot nu toe hebben we 00:07.740 --> 00:10.230 het eigenlijk alleen over IPv4 gehad, maar 00:10.230 --> 00:13.020 een van de problemen die we hebben met IPv4 is dat 00:13.020 --> 00:15.510 het beperkt is in zijn adresruimte. 00:15.510 --> 00:17.370 Dit komt omdat een IPv4-adres 00:17.370 --> 00:19.380 uit slechts 32 bits bestaat, waardoor 00:19.380 --> 00:23.070 we er maar 4 hebben. 2 miljard mogelijke adrescombinaties. 00:23.070 --> 00:26.430 Nu ken ik er 4. 2 miljard klinkt als een heleboel 00:26.430 --> 00:28.950 IP's, maar toen we er hele delen uithaalden, zoals 00:28.950 --> 00:32.160 APIPA adressen, lokale host adressen, privé IP's, en toen was 00:32.160 --> 00:34.770 er een enorme hoeveelheid afval voordat we zelfs 00:34.770 --> 00:36.720 subnetten begonnen te gebruiken, leidde 00:36.720 --> 00:38.670 dit tot een groot probleem en begonnen 00:38.670 --> 00:41.040 we een tekort aan netwerkadressen binnen IPv4 00:41.040 --> 00:42.810 te krijgen. 00:42.810 --> 00:46.860 Dit staat bekend als adresuitputting en het bestaat echt. 00:46.860 --> 00:49.260 In november 2019 hebben RIPE NCC, het 00:49.260 --> 00:51.810 regionale internetregister voor Europa, 00:51.810 --> 00:56.160 West-Azië en de voormalige USSR, en NASA hun volledige voorraad 00:56.160 --> 00:59.130 IPv4-adressen al opgebruikt. 00:59.130 --> 01:01.770 Gelukkig was de Internet Engineering 01:01.770 --> 01:04.740 Task Force, of IETF, al begonnen met het kijken 01:04.740 --> 01:06.600 naar de toekomst en zij ontwikkelden 01:06.600 --> 01:09.690 IPv6 als standaard helemaal terug in 1995 met 01:09.690 --> 01:13.380 een RFC die hun visie voor IPv6 documenteerde, die ze 01:13.380 --> 01:17.790 IP Next Generation of IPNG noemden. 01:17.790 --> 01:22.790 Nu zie je dat IPv6 eigenlijk een enorme verbetering is ten opzichte van IPv4 wat betreft 01:22.860 --> 01:25.290 het aantal beschikbare adressen. 01:25.290 --> 01:28.710 In plaats van een 32-bits adres zoals in IPv4, 01:28.710 --> 01:32.100 gaat IPv6 een 128-bits adres gebruiken. 01:32.100 --> 01:35.490 Dit geeft je een veel grotere adresruimte. 01:35.490 --> 01:37.620 In feite geeft het je een mogelijkheid 01:37.620 --> 01:41.430 van 340 miljard IP-adressen. 01:41.430 --> 01:42.930 Dat zijn genoeg IP-adressen 01:42.930 --> 01:45.930 voor elke man, vrouw en kind op deze planeet. 01:45.930 --> 01:48.540 Dit is twee tot de 128e macht. 01:48.540 --> 01:51.300 In feite zijn er heel veel IP-adressen voor elke 01:51.300 --> 01:53.730 man, vrouw en kind op deze planeet omdat er 01:53.730 --> 01:56.250 zoveel IP-adressen beschikbaar zijn. 01:56.250 --> 01:57.960 Nu vraag je je misschien 01:57.960 --> 02:01.230 af: hé, we zijn van IPv4 naar IPv6 gegaan. 02:01.230 --> 02:03.090 Wat is er gebeurd met versie 5? 02:03.090 --> 02:05.370 Waarom zijn we meteen naar versie 6 gesprongen? 02:05.370 --> 02:09.180 Welnu, versie 5 werd gemaakt, maar het werd nooit volledig aangenomen als 02:09.180 --> 02:11.190 een officieel protocol of standaard. 02:11.190 --> 02:13.350 En daarom is het nooit in productie gegaan. 02:13.350 --> 02:14.820 In plaats daarvan werden veel van 02:14.820 --> 02:16.350 die concepten die ontwikkeld werden 02:16.350 --> 02:17.970 onder versie 5, omdat het een experimenteel 02:17.970 --> 02:19.920 protocol was, in IPv6 gebracht toen het een 02:19.920 --> 02:21.870 officiële standaard werd. 02:21.870 --> 02:25.650 Laten we het eens hebben over de voordelen van IPv6. 02:25.650 --> 02:26.910 Een van de grootste voordelen 02:26.910 --> 02:28.890 is die veel grotere adresruimte vanwege 02:28.890 --> 02:31.350 die 128-bits adressen. 02:31.350 --> 02:32.460 Daarnaast heeft IPv6 02:32.460 --> 02:35.160 ook de efficiëntie van onze netwerken verhoogd door 02:35.160 --> 02:38.730 het type broadcast-gegevensstroom van IPv4 te verwijderen. 02:38.730 --> 02:41.250 Nu is IPv6 ook veiliger omdat er geen 02:41.250 --> 02:44.010 pakket- of datagramfragmentatie is binnen 02:44.010 --> 02:46.050 de IPv6-standaard. 02:46.050 --> 02:48.150 Er zijn ook geen maximale transmissie-eenheden 02:48.150 --> 02:51.330 voor ontdekking binnen elke sessie, in tegenstelling tot IPv4 02:51.330 --> 02:54.870 dat een MTU met een bepaalde grootte voor elk pakket bevat. 02:54.870 --> 02:57.030 In IPv4, als ik je een pakket stuur dat groter is 02:57.030 --> 02:59.820 dan de maximale grootte van je transmissie-eenheid, dan wordt 02:59.820 --> 03:01.080 dat gefragmenteerd en over 03:01.080 --> 03:02.400 het netwerk verstuurd. 03:02.400 --> 03:04.110 En als het dan op zijn bestemming aankwam, 03:04.110 --> 03:05.970 werd het weer in elkaar gezet en gelezen. 03:05.970 --> 03:07.650 Dit was eigenlijk een veiligheidsrisico. 03:07.650 --> 03:09.540 Het vereiste ook extra verwerking en het kon 03:09.540 --> 03:11.460 je netwerken feitelijk vertragen omdat het 03:11.460 --> 03:13.920 een zeer inefficiënte manier werd om dingen te doen in onze 03:13.920 --> 03:15.120 moderne netwerken met hogere 03:15.120 --> 03:17.070 internetverbindingssnelheden. 03:17.070 --> 03:19.830 Dus met IPv6 besloten ze om fragmentatie 03:19.830 --> 03:21.900 helemaal af te schaffen. 03:21.900 --> 03:24.480 Naast het bieden van al deze nieuwe voordelen, 03:24.480 --> 03:26.970 waren de makers van IPv6 ook erg slim en realiseerden 03:26.970 --> 03:30.690 ze zich dat IPv6, om volledig omarmd en geaccepteerd te worden, achterwaarts 03:30.690 --> 03:33.630 compatibel moest zijn met IPv4 en zowel IPv6 als IPv4 03:33.630 --> 03:38.630 naast elkaar moest laten bestaan op hetzelfde netwerk. 03:38.700 --> 03:41.490 Het was immers al laat in de jaren 90 toen IPv6 werd 03:41.490 --> 03:45.270 ontwikkeld en uitgebracht en er al veel computernetwerken over 03:45.270 --> 03:47.490 de hele wereld waren opgezet. 03:47.490 --> 03:48.900 Het zou voor ons dus niet 03:48.900 --> 03:51.960 haalbaar zijn om alles in één dag te veranderen. 03:51.960 --> 03:53.490 Zie het als de huidige migratie van voertuigen 03:53.490 --> 03:55.170 die op gas rijden naar voertuigen die op 03:55.170 --> 03:56.730 elektriciteit rijden. 03:56.730 --> 03:58.920 Dit gebeurt de hele jaren 03:58.920 --> 04:00.420 2020 en 2030. 04:00.420 --> 04:02.970 Het zou nu onmogelijk zijn om te zeggen: 04:02.970 --> 04:05.850 "Hé, iedereen, op 1 januari 2025 mag niemand 04:05.850 --> 04:07.710 meer op gas rijden. 04:07.710 --> 04:08.700 Vanaf die datum worden ze 04:08.700 --> 04:11.010 allemaal vervangen door elektrische voertuigen. 04:11.010 --> 04:12.180 Als een regering dat zou proberen, 04:12.180 --> 04:14.160 zouden ze waarschijnlijk een revolutie op hun 04:14.160 --> 04:17.190 hand hebben omdat zoveel mensen al auto's op gas bezitten en een hoop geld 04:17.190 --> 04:19.890 en investeringen hebben uitgegeven aan die auto's en de infrastructuur 04:19.890 --> 04:21.900 om ze te ondersteunen. 04:21.900 --> 04:24.480 Daarom gaan we niet van de ene op de andere dag 04:24.480 --> 04:26.250 alle auto's op gas vervangen. 04:26.250 --> 04:28.680 In plaats daarvan zal er een langzame overgang zijn van 04:28.680 --> 04:32.130 gas naar elektriciteit, die doorgaat tot 2030 of misschien 2040 als steeds 04:32.130 --> 04:34.890 meer van de nieuwere auto's die in de wereld worden verkocht, 04:34.890 --> 04:37.050 elektrisch zullen zijn en ze zullen stoppen met 04:37.050 --> 04:39.390 het verkopen van auto's die op gas rijden. 04:39.390 --> 04:42.900 Nou, precies hetzelfde is aan de hand met IPv6. 04:42.900 --> 04:47.010 IPv6 zorgt er dus voor dat IPv4 en IPv6 naast elkaar kunnen bestaan op 04:47.010 --> 04:49.140 dezelfde netwerken en de apparatuur 04:49.140 --> 04:51.360 waarop deze netwerken draaien wordt 04:51.360 --> 04:53.370 dual stack genoemd, wat simpelweg 04:53.370 --> 04:54.930 betekent dat ze zowel IPv4-protocollen 04:54.930 --> 04:58.200 als IPv6-protocollen tegelijk kunnen draaien op dezelfde 04:58.200 --> 05:01.080 netwerkapparaten. 05:01.080 --> 05:04.410 Met dual stack apparaten, als een client IPv6 ondersteunt, zal 05:04.410 --> 05:06.960 de switch van de router bij voorkeur IPv6 gebruiken 05:06.960 --> 05:08.760 en volgens die methode praten. 05:08.760 --> 05:11.370 Als een apparaat IPv6 niet ondersteunt, draait 05:11.370 --> 05:13.080 het zichzelf om en zegt: "Oké, 05:13.080 --> 05:16.380 ik praat met je via het oudere IPv4-protocol. 05:16.380 --> 05:18.390 Op deze manier kan ik je nog steeds steunen. 05:18.390 --> 05:20.850 Een andere methode die we gebruiken staat bekend als tunneling. 05:20.850 --> 05:24.780 Hier wordt IPv6 getunneld over een IPv4-apparaat. 05:24.780 --> 05:27.150 Hierdoor kunnen uw oudere IPv4-routers 05:27.150 --> 05:29.580 nog steeds IPv6-verkeer verwerken. 05:29.580 --> 05:31.710 IPv6 wordt in wezen getunneld als een 05:31.710 --> 05:34.860 mechanisme om IPv6-pakketten in te kapselen in IPv4-headers 05:34.860 --> 05:38.370 en deze IPv6-gegevens over IPv4-routers en andere reeds 05:38.370 --> 05:42.480 bestaande infrastructuur te transporteren. 05:42.480 --> 05:44.640 Het doet dit door een punt-tot-punt tunnel aan te 05:44.640 --> 05:46.380 maken tussen de bron en de bestemming en 05:46.380 --> 05:48.450 die informatie vervolgens in te kapselen. 05:48.450 --> 05:51.630 Hierdoor kunnen geïsoleerde IPv6-clients en -servers met elkaar 05:51.630 --> 05:53.310 communiceren zonder dat alle routers 05:53.310 --> 05:55.620 en switchinfrastructuur die nog IPv4 gebruikt 05:55.620 --> 05:59.040 en tussen hen in staat, geüpgraded hoeven te worden. 05:59.040 --> 06:02.880 Op een dag zullen we misschien zien dat IPv4 volledig wordt afgeschaft. 06:02.880 --> 06:05.070 Maar tot nu toe is dat niet gebeurd. 06:05.070 --> 06:07.440 En persoonlijk houd ik mijn adem niet in. 06:07.440 --> 06:08.670 Uit sommige artikelen 06:08.670 --> 06:11.160 die ik heb gelezen, blijkt dat IPv4 nog minstens 06:11.160 --> 06:14.340 tot 2040 zal blijven bestaan, dus je zult als netwerktechnicus 06:14.340 --> 06:17.430 moeten weten hoe je in de nabije toekomst met zowel 06:17.430 --> 06:20.640 IPv4 als IPv6 moet werken. 06:20.640 --> 06:24.120 Een ander voordeel van IPv6 is dat het een vereenvoudigde header heeft. 06:24.120 --> 06:26.850 Dus in plaats van de 12 velden die we in IPv4 hadden, hebben 06:26.850 --> 06:29.430 we er maar vijf in IPv6, waardoor het een afgeslankte 06:29.430 --> 06:30.960 header is die veel efficiënter 06:30.960 --> 06:33.630 over onze netwerken kan worden verzonden. 06:33.630 --> 06:35.370 Je vraagt je dus misschien 06:35.370 --> 06:37.920 af hoe een IPv6-header eruit ziet? 06:37.920 --> 06:40.500 Nou, ik ga het je laten zien, maar besef wel dat je dit niet 06:40.500 --> 06:42.750 uit je hoofd hoeft te leren voor het examen. 06:42.750 --> 06:44.940 In plaats daarvan laat dit alleen de verschillende 06:44.940 --> 06:47.040 velden zien die in IPv4 zaten, wat bovenaan staat, 06:47.040 --> 06:49.230 tegenover IPv6, wat onderaan staat. 06:49.230 --> 06:51.240 En nu kun je zien hoeveel eenvoudiger 06:51.240 --> 06:54.450 IPv6 eigenlijk is dan IPv4. 06:54.450 --> 06:56.190 Oké, laten we teruggaan naar de dingen 06:56.190 --> 06:58.170 die je moet begrijpen voor het examen. 06:58.170 --> 07:01.590 Hoe ziet een IPv6-adres er eigenlijk uit? 07:01.590 --> 07:04.590 Nou, ik heb al gezegd dat het 128 bits lang is, dus dat 07:04.590 --> 07:08.160 betekent dat het 128 enen of nullen zou hebben als we het binair 07:08.160 --> 07:09.600 zouden uitschrijven, en 07:09.600 --> 07:11.910 dat lijkt me een heel slecht idee, dus dat 07:11.910 --> 07:13.410 gaan we niet doen. 07:13.410 --> 07:15.210 Nu zouden we de gestippelde decimale 07:15.210 --> 07:16.680 notatie kunnen gebruiken zoals 07:16.680 --> 07:19.020 we deden in IPv4, maar dat zijn nog steeds veel octetten 07:19.020 --> 07:23.670 om uit te schrijven omdat we 16 octetten nodig hebben om alle 128 bits weer te geven. 07:23.670 --> 07:25.380 Om dit probleem op te lossen, besloot 07:25.380 --> 07:27.360 de IETF dat we in plaats daarvan hexadecimale 07:27.360 --> 07:29.310 cijfers moesten gebruiken. 07:29.310 --> 07:31.860 Zie je, hexadecimaal is basis-16, wat je je al dan niet 07:31.860 --> 07:33.150 herinnert van je algebra-lessen 07:33.150 --> 07:34.980 op de middelbare school. 07:34.980 --> 07:36.210 In hexadecimaal is elk 07:36.210 --> 07:38.760 hexadecimaal cijfer eigenlijk vier bits. 07:38.760 --> 07:41.250 Hiermee kunnen we een IPv6-adres weergeven 07:41.250 --> 07:43.710 door vier hexadecimale cijfers te combineren 07:43.710 --> 07:45.780 tot wat we een segment noemen. 07:45.780 --> 07:48.720 Een segment bevat 16 bits. 07:48.720 --> 07:51.030 Dit wordt weergegeven door die vier hexadecimale cijfers. 07:51.030 --> 07:52.440 En dan voegen we een dubbele 07:52.440 --> 07:53.880 punt toe en dan blijven we segmenten 07:53.880 --> 07:56.250 toevoegen tot we bij 128 bits zijn, waarvoor 07:56.250 --> 07:57.900 acht segmenten nodig zijn, elk 07:57.900 --> 08:00.510 met vier hexadecimale cijfers. 08:00.510 --> 08:03.510 Dit geeft me een totaal van 32 hexadecimale cijfers, wat 08:03.510 --> 08:05.460 nog steeds behoorlijk lang is. 08:05.460 --> 08:09.330 Met 128 bits in een IPv6-adres betekent dit dat we 08:09.330 --> 08:12.810 niet meer dan 32 hexadecimale cijfers in al deze 08:12.810 --> 08:14.700 segmenten hebben. 08:14.700 --> 08:18.150 Waarom zei ik niet meer dan 32 cijfers voor het totaal 08:18.150 --> 08:20.250 van deze acht segmenten? 08:20.250 --> 08:22.800 Waarom zouden het niet gewoon 32 hexadecimale 08:22.800 --> 08:25.710 cijfers zijn, omdat 32 cijfers maal vier bits per 08:25.710 --> 08:28.290 cijfer ons 128 bits zou geven? 08:28.290 --> 08:31.320 Dit komt omdat IPv6 ons eigenlijk toestaat om een 08:31.320 --> 08:33.450 steno te gebruiken om onze erg lange 08:33.450 --> 08:35.880 IPv6-adressen te vereenvoudigen. 08:35.880 --> 08:37.980 De regels voor steno zijn erg belangrijk 08:37.980 --> 08:40.650 omdat je hier examenvragen over kunt krijgen. 08:40.650 --> 08:43.020 Dus als je vier nullen hebt voor een segment, 08:43.020 --> 08:45.360 kun je daar één nul neerzetten en die voorloopnullen 08:45.360 --> 08:47.310 weglaten. 08:47.310 --> 08:50.790 Laten we bijvoorbeeld doen alsof ik een heel lang 08:50.790 --> 08:55.790 IPv6-adres heb van 2018:0000:0000:0000:0000:0000:4815:54ae. 09:04.470 --> 09:05.820 Met behulp van de eenvoudige 09:05.820 --> 09:08.490 regel kan ik alle segmenten met meerdere nullen vervangen 09:08.490 --> 09:09.810 door een enkele nul. 09:09.810 --> 09:14.810 Dit zou me 2018:0:0:0:4815:54ae geven. 09:19.590 --> 09:22.680 Oké, dit bracht mijn aantal hexadecimale cijfers 09:22.680 --> 09:26.790 terug van 32 naar slechts 17, dus het is ongeveer de helft langer. 09:26.790 --> 09:29.520 Het gaat steeds beter, maar daar wil ik het niet bij laten. 09:29.520 --> 09:30.710 Er is nog een regel die ik 09:30.710 --> 09:33.000 kan gebruiken in de wereld van IPv6 steno. 09:33.000 --> 09:35.280 Deze regel zegt dat als er meerdere segmenten zijn 09:35.280 --> 09:36.840 met allemaal nullen erin en er geen 09:36.840 --> 09:39.420 andere hexadecimale cijfers worden weergegeven, ik dat 09:39.420 --> 09:42.150 kan samenvatten door een dubbele dubbele punt te gebruiken 09:42.150 --> 09:44.160 en al die nullen eruit te halen. 09:44.160 --> 09:45.420 Deze regel is speciaal 09:45.420 --> 09:48.540 omdat je de dubbele dubbele punt maar één keer in een 09:48.540 --> 09:50.460 IPv6-adres kunt gebruiken. 09:50.460 --> 09:52.530 Dus met behulp van mijn dubbele dubbele 09:52.530 --> 09:57.530 punt regel, kan ik 2018:0:0:0:4815:54ae samenvatten in het verwijderen van al 10:00.750 --> 10:03.270 die vijf sets nullen en ze vervangen door 10:03.270 --> 10:04.950 een dubbele dubbele punt en 10:04.950 --> 10:07.450 krijg ik 2018::4815::54ae. 10:10.290 --> 10:13.020 Dus ik ging van 32 hexadecimale cijfers naar 10:13.020 --> 10:14.910 17 hexadecimale cijfers en nu 10:14.910 --> 10:17.160 ben ik van 17 cijfers helemaal terug 10:17.160 --> 10:19.080 naar 12 cijfers, veel kleiner, 10:19.080 --> 10:21.690 veel gemakkelijker om mee te werken. 10:21.690 --> 10:24.240 Je kunt zien hoe dit steno echt nuttig is. 10:24.240 --> 10:27.150 Dus hoe ga je een IPv6-adres herkennen ten opzichte 10:27.150 --> 10:28.950 van een IPv4-adres? 10:28.950 --> 10:32.130 De eerste manier is door te kijken naar wat IPv4 is. 10:32.130 --> 10:35.400 IPv4 gebruikt altijd de gestippelde decimale notatie 10:35.400 --> 10:36.990 met vier octetten. 10:36.990 --> 10:38.490 IPv6 daarentegen gebruikt 10:38.490 --> 10:40.530 dubbele punten tussen de getallen en 10:40.530 --> 10:42.450 wordt hexadecimaal geschreven. 10:42.450 --> 10:44.280 Goed, een van de vragen die je op de 10:44.280 --> 10:45.810 testdag zou kunnen tegenkomen 10:45.810 --> 10:49.080 is om een IPv6-adres te herkennen als je er een ziet. 10:49.080 --> 10:51.180 Je kunt bijvoorbeeld een vraag krijgen 10:51.180 --> 10:53.700 als, welk van de volgende is een IPv6-adres? 10:53.700 --> 10:55.410 Dit is een eerlijke vraag. 10:55.410 --> 10:59.280 Je krijgt een aantal opties zoals 192. 168. 1. 1, waarvan we weten 10:59.280 --> 11:01.830 dat dit het niet is omdat het een IPv4 adres is. 11:01.830 --> 11:06.830 Je krijgt 12:34:56:78:90:AB 11:07.590 --> 11:12.000 of 1234::5678::90AB. 11:12.000 --> 11:15.120 Dus wacht eens even, die laatste twee die ik net zei, die 11:15.120 --> 11:17.010 lijken echt op elkaar, toch? 11:17.010 --> 11:20.310 Ja, maar slechts één daarvan is een geldig IPv6-adres. 11:20.310 --> 11:21.630 Weet je welke het is? 11:21.630 --> 11:24.000 Omdat de meeste studenten hier in de war raken. 11:24.000 --> 11:28.020 De tweede optie hier is eigenlijk geen IPv6-adres. 11:28.020 --> 11:29.820 In plaats daarvan is het een MAC-adres. 11:29.820 --> 11:31.260 Onthoud dat MAC-adressen, die 11:31.260 --> 11:33.060 een Layer 2 fysiek adres zijn, altijd 11:33.060 --> 11:35.580 12 hexadecimale cijfers bevatten en worden gescheiden 11:35.580 --> 11:37.230 door dubbele punten. 11:37.230 --> 11:38.370 Meestal worden ze geschreven 11:38.370 --> 11:40.410 als zes groepen van elk twee cijfers en elk daarvan 11:40.410 --> 11:43.200 wordt gescheiden door een enkele dubbele punt. 11:43.200 --> 11:46.080 Een IPv6-adres daarentegen moet altijd worden geschreven 11:46.080 --> 11:48.120 in segmenten van vier cijfers elk, en ze 11:48.120 --> 11:50.580 moeten altijd 16 segmenten hebben, tenzij je een 11:50.580 --> 11:52.500 dubbele dubbele punt ziet. 11:52.500 --> 11:55.080 In dit voorbeeld hebben we een dubbele dubbele punt 11:55.080 --> 11:58.020 tussen het eerste en tweede segment in onze derde optie. 11:58.020 --> 12:00.840 Dit is dus een goede stenografie die we kunnen gebruiken 12:00.840 --> 12:03.450 en we kunnen identificeren dat het een IPv6 adres 12:03.450 --> 12:05.130 is omdat we alle nullen tussen het 12:05.130 --> 12:08.520 eerste en tweede segment in dit adres hebben verwijderd. 12:08.520 --> 12:09.960 Dus als je iets telt dat eruit 12:09.960 --> 12:11.790 ziet als een IPv6-adres en het heeft 12:11.790 --> 12:15.480 12, precies 12 hexadecimale cijfers gescheiden door enkele dubbele 12:15.480 --> 12:17.040 punten, en je ziet nergens 12:17.040 --> 12:18.840 een dubbele dubbele punt, dan is 12:18.840 --> 12:22.140 dat een MAC-adres, geen IPv6-adres. 12:22.140 --> 12:24.180 Anders, als het er ongeveer zo uitziet 12:24.180 --> 12:25.860 en hexadecimale cijfers bevat, 12:25.860 --> 12:29.190 wordt het een IPv6-adres op de examendag. 12:29.190 --> 12:31.440 Voor het examen hoef je alleen maar te herkennen 12:31.440 --> 12:33.540 hoe een IPv6-adres eruit ziet en je moet er 12:33.540 --> 12:35.790 een kunnen samenvatten door nullen weg te halen 12:35.790 --> 12:38.070 en ze samen te voegen met behulp van die dubbele 12:38.070 --> 12:39.960 dubbele punt-truc. 12:39.960 --> 12:41.490 Als je deze twee dingen kunt 12:41.490 --> 12:45.000 doen, zit je goed voor IPv6 adressering op de examendag. 12:45.000 --> 12:47.280 Wanneer het aankomt op IPv6-adressering, 12:47.280 --> 12:50.100 zijn er drie verschillende adrestypes die je kunt gebruiken: 12:50.100 --> 12:52.220 unicast-adressen, multicast-adressen 12:52.220 --> 12:54.210 en anycast-adressen. 12:54.210 --> 12:56.640 Een van de interessante dingen van IPv6 die 12:56.640 --> 12:59.040 het echt onderscheidt van IPv4 is dat we meerdere 12:59.040 --> 13:01.830 IPv6 adressen kunnen toewijzen aan een enkele interface 13:01.830 --> 13:03.900 op een client. 13:03.900 --> 13:05.730 En deze opdrachten kunnen een mengeling 13:05.730 --> 13:07.680 zijn van deze drie verschillende types: 13:07.680 --> 13:10.290 unicast, multicast en anycast. 13:10.290 --> 13:13.140 Dus zelfs als je maar één netwerkinterfacekaart 13:13.140 --> 13:14.910 op je werkstation of laptop hebt, 13:14.910 --> 13:17.430 kun je meerdere IPv6-adressen en verschillende 13:17.430 --> 13:19.860 soorten IPv6-adressen hebben die aan die 13:19.860 --> 13:22.140 ene kaart zijn toegewezen. 13:22.140 --> 13:23.850 Unicast adressen gaan gebruikt worden 13:23.850 --> 13:25.950 om een enkele interface te identificeren. 13:25.950 --> 13:28.950 Deze worden onderverdeeld in globally-routed unicast 13:28.950 --> 13:30.930 adressen en link-local adressen. 13:30.930 --> 13:32.760 Een globaal gerouteerd unicast-adres 13:32.760 --> 13:36.150 is vergelijkbaar met wat we hebben als een openbaar adres met 13:36.150 --> 13:39.600 IPv4 met unicast-adressen van de A-, B- en C-klasse. 13:39.600 --> 13:42.840 In IPv6 begint een globally-routed 13:42.840 --> 13:44.220 unicast adres altijd 13:44.220 --> 13:49.050 met het eerste segment dat 2000-3999 bevat. 13:49.050 --> 13:52.740 Als je nu 2000-3999 ziet als je eerste segment, betekent dit 13:52.740 --> 13:55.770 dat het een globaal gerouteerd unicast adres is. 13:55.770 --> 13:58.050 Bijvoorbeeld, het IPv6 adres 13:58.050 --> 14:03.050 2584:0db8:8583:1234:5678:882e:0370:7334 zou globaal 14:10.800 --> 14:14.010 gerouteerd worden als een unicast adres 14:14.010 --> 14:17.070 omdat het eerste segment 2584 bevat, 14:17.070 --> 14:20.670 wat tussen 2000 en 3999 ligt. 14:20.670 --> 14:22.650 Een link-local adres daarentegen, 14:22.650 --> 14:24.690 ook wel een lokaal gebruiksadres genoemd, 14:24.690 --> 14:28.020 wordt gebruikt zoals een privé IP-adres in IPv4. 14:28.020 --> 14:29.970 Een link-local adres in IPv6 14:29.970 --> 14:32.097 kan alleen worden gebruikt op 14:32.097 --> 14:36.840 een lokaal netwerk en begint altijd met FE80 als eerste segment 14:36.840 --> 14:38.940 binnen een IPv6-adres. 14:38.940 --> 14:41.760 Wanneer nu een IPv6 systeem opstart, wordt er een 14:41.760 --> 14:44.100 link-local adres aangemaakt voor elke IPv6 14:44.100 --> 14:47.070 interface op dat systeem, zelfs als er al een globally-routable 14:47.070 --> 14:50.190 adres handmatig was geconfigureerd of verkregen via 14:50.190 --> 14:53.700 een configuratieprotocol zoals DHCP. 14:53.700 --> 14:56.340 Om dit te doen gebruikt het iets dat bekend staat 14:56.340 --> 15:00.840 als SLAAC, de stateless address auto-configuration of S-L-A-A-C. 15:00.840 --> 15:02.610 Met stateless auto-configuration 15:02.610 --> 15:04.680 hoeft de host geen adressen of andere configuratie-informatie 15:04.680 --> 15:06.210 te verkrijgen van een gecentraliseerde 15:06.210 --> 15:08.880 server zoals DHCP. 15:08.880 --> 15:11.640 In plaats daarvan kan het zichzelf onafhankelijk een link-local 15:11.640 --> 15:13.050 adres toewijzen, de uniekheid 15:13.050 --> 15:15.420 van dat link-local adres testen, het link-local adres 15:15.420 --> 15:17.430 aan zichzelf toewijzen, contact opnemen met 15:17.430 --> 15:20.220 de router en het knooppunt aanwijzingen geven over hoe verder 15:20.220 --> 15:22.680 te gaan met de autoconfiguratie. 15:22.680 --> 15:25.770 En het kan zelfs het globale unicast adres configureren 15:25.770 --> 15:27.090 dat het wil gebruiken. 15:27.090 --> 15:29.520 We zullen over een paar minuten terugkomen op dit 15:29.520 --> 15:31.110 concept als we er wat dieper op ingaan 15:31.110 --> 15:34.080 en beginnen te praten over EUI-64 en het neighbor discovery 15:34.080 --> 15:35.580 protocol, aangezien beide processen 15:35.580 --> 15:37.650 worden gebruikt met het stateless address 15:37.650 --> 15:40.140 auto-configuration protocol dat bekend staat als 15:40.140 --> 15:41.580 SLAAC. 15:41.580 --> 15:43.680 Vervolgens hebben we multicast-adressen. 15:43.680 --> 15:45.360 Nu worden multicastadressen gebruikt om 15:45.360 --> 15:47.100 een groep interfaces te identificeren zodat 15:47.100 --> 15:49.710 een pakket naar een multicastadres kan worden gestuurd en vervolgens 15:49.710 --> 15:52.680 bij alle interfaces binnen een groep kan worden afgeleverd. 15:52.680 --> 15:56.550 In IPv6 zal een multicast-adres altijd FF bevatten als de eerste 15:56.550 --> 15:59.460 twee cijfers binnen het eerste segment. 15:59.460 --> 16:02.280 Als je FF aan het begin van een IPv6-adres ziet 16:02.280 --> 16:04.800 staan, denk dan aan de multicast. 16:04.800 --> 16:06.330 Het laatste type adres dat we 16:06.330 --> 16:08.700 hebben staat bekend als een anycast adres. 16:08.700 --> 16:11.610 Anycast adressen worden gebruikt om een set interfaces te identificeren 16:11.610 --> 16:14.400 zodat een pakket naar elk lid van een set kan worden gestuurd. 16:14.400 --> 16:16.320 Anycast-adressen worden eigenlijk toegewezen 16:16.320 --> 16:18.060 uit de unicast-adresruimte. 16:18.060 --> 16:19.620 Er is dus echt geen manier om 16:19.620 --> 16:22.710 te bepalen of een IPv6-adres unicast of anycast is door 16:22.710 --> 16:25.410 alleen maar naar het IPv6-adres te kijken. 16:25.410 --> 16:28.050 Als je nu kijkt naar multicast of link-local, dan heb je 16:28.050 --> 16:29.790 een erg makkelijke manier om dit te doen, 16:29.790 --> 16:31.440 maar je hebt geen makkelijke manier 16:31.440 --> 16:33.870 om unicast versus anycast uit te zoeken. 16:33.870 --> 16:35.010 Goed, laten we teruggaan 16:35.010 --> 16:36.990 en wat meer praten over SLAAC, het stateless 16:36.990 --> 16:40.140 address auto-configuration proces. 16:40.140 --> 16:42.090 Nu, zoals ik al zei, is er in IPv6 een auto-configuratieproces 16:42.090 --> 16:45.120 dat bekend staat als SLAAC, en we gebruiken dit om het huidige 16:45.120 --> 16:48.570 netwerk te ontdekken waarop de interface zich bevindt en staan 16:48.570 --> 16:51.360 het dan toe om zijn eigen host-ID te kiezen op basis van 16:51.360 --> 16:56.360 zijn MAC-adres met behulp van een proces dat EUI-64 heet. 16:56.550 --> 17:01.410 Met dit EUI-64 of Extended Unique Identifier proces kan een host 17:01.410 --> 17:03.450 zichzelf een unieke 64-bit 17:03.450 --> 17:07.967 IPv6 interface identifier toewijzen, EUI-64 genaamd. 17:09.180 --> 17:12.000 Nu wordt dit EUI-64 formaatadres verkregen door 17:12.000 --> 17:15.480 het 48-bit MAC-adres van de interface te gebruiken. 17:15.480 --> 17:19.260 Het MAC-adres wordt eerst gescheiden in twee delen van 24 bits. 17:19.260 --> 17:22.890 De eerste helft van het MAC-adres bevat de OUI, of de Organizational 17:22.890 --> 17:25.170 Unique Identifier. 17:25.170 --> 17:26.850 En de tweede helft bevat de specifieke 17:26.850 --> 17:29.010 netwerkinterfacekaart. 17:29.010 --> 17:30.780 Daartussen stoppen 17:30.780 --> 17:35.730 we een 16-bits hexadecimale waarde van FFFE. 17:35.730 --> 17:39.990 Op deze manier kan ik 24 bits, 16 bits en 24 17:39.990 --> 17:44.760 bits samenvoegen tot een 64-bits EUI-adres. 17:44.760 --> 17:47.340 Dit geeft je de 64 bits die je nodig hebt om je interface 17:47.340 --> 17:49.860 op dat netwerk te identificeren. 17:49.860 --> 17:52.320 Dan zal de interface autodiscovery gebruiken 17:52.320 --> 17:53.910 om het netwerk te bepalen waarop 17:53.910 --> 17:57.030 het zich bevindt en het netwerkgedeelte van het IPv6 adres 17:57.030 --> 18:00.960 toevoegen, dat de eerste 64 bits in onze adressen zullen zijn. 18:00.960 --> 18:02.940 Nu zetten we de eerste 64 bits die 18:02.940 --> 18:05.580 het netwerk voorstellen voor de 64 bits van 18:05.580 --> 18:09.390 het EUI-64 adres dat we hebben gemaakt van ons MAC-adres om een 18:09.390 --> 18:13.050 unicast globaal routeerbaar IPv6-adres te maken dat we nu 18:13.050 --> 18:14.550 kunnen gebruiken. 18:14.550 --> 18:16.890 Je kunt dus zien hoe dit alles samenwerkt door 18:16.890 --> 18:18.180 dat MAC-adres te gebruiken 18:18.180 --> 18:20.700 om dit globaal routeerbare adres te maken. 18:20.700 --> 18:24.180 Nu kan DHCP ook gebruikt worden binnen IPv6 als je dat 18:24.180 --> 18:25.560 liever gebruikt. 18:25.560 --> 18:29.520 Als je dat doet, moet je het DHCPv6-protocol gebruiken. 18:29.520 --> 18:30.930 Hierdoor zou je DHCP automatisch 18:30.930 --> 18:34.650 dingen kunnen laten toewijzen vanaf een DHCPv6 server. 18:34.650 --> 18:38.520 Maar omdat het autoconfiguratieproces met EUI-64 al standaard is 18:38.520 --> 18:41.430 ingebouwd in het IPv6-protocol, hoef je eigenlijk 18:41.430 --> 18:43.230 geen DHCPv6 te gebruiken. 18:44.280 --> 18:47.580 Maar als je DHCPv6 wil gebruiken, dan kan dat en het zal je toelaten 18:47.580 --> 18:48.870 om toe te wijzen welke adressen 18:48.870 --> 18:51.360 elke interface zal krijgen in plaats van ze toe te 18:51.360 --> 18:52.500 laten om het autoconfiguratieprotocol 18:52.500 --> 18:55.170 van SLAAC te gebruiken. 18:55.170 --> 18:58.560 Zoals ik al zei kiest IPv6 standaard zijn eigen adres op 18:58.560 --> 19:00.930 basis van het MAC-adres, daarna gebruikt 19:00.930 --> 19:03.480 het NDP of het neighbor discovery protocol 19:03.480 --> 19:05.310 om meer te weten te komen over 19:05.310 --> 19:08.370 de andere Layer 2 adressen op het netwerk op basis 19:08.370 --> 19:09.990 van hun MAC-adressen en kiest 19:09.990 --> 19:12.630 dan zijn eigen host-ID. 19:12.630 --> 19:15.630 Voor het examen hoef je NDP niet grondig te kennen, maar je moet 19:15.630 --> 19:17.850 wel begrijpen dat NDP, dit neighbor discovery 19:17.850 --> 19:20.847 protocol, gebruikt wordt in IPv6 en het neemt veel van de functies 19:20.847 --> 19:22.410 van routeradvertentie en neighbor 19:22.410 --> 19:25.683 discovery over en handelt ze voor je af.