WEBVTT 00:00.090 --> 00:01.050 Instruktor: W tej 00:01.050 --> 00:04.200 lekcji przedstawimy koncepcje związane z IPv6, czyli 00:04.200 --> 00:06.600 protokołem internetowym w wersji 6. 00:06.600 --> 00:07.740 Do tej pory rozmawialiśmy 00:07.740 --> 00:10.230 tylko o IPv4, ale jednym z problemów 00:10.230 --> 00:13.020 związanych z IPv4 jest ograniczona przestrzeń 00:13.020 --> 00:15.510 adresowa. 00:15.510 --> 00:17.370 Dzieje się tak, ponieważ adres 00:17.370 --> 00:19.380 IPv4 składa się tylko z 32 bitów, 00:19.380 --> 00:23.070 co daje nam tylko 4. 2 miliardy możliwych kombinacji adresów. 00:23.070 --> 00:26.430 Teraz znam 4. 2 miliardy wydaje się dużą liczbą 00:26.430 --> 00:28.950 adresów IP, ale kiedy usunęliśmy całe części rzeczy, 00:28.950 --> 00:32.160 takie jak adresy APIPA, adresy hostów lokalnych, prywatne adresy 00:32.160 --> 00:34.770 IP, a następnie pojawiła się ogromna ilość odpadów, 00:34.770 --> 00:36.720 zanim jeszcze zaczęliśmy używać podsieci, 00:36.720 --> 00:38.670 doprowadziło to do dużego problemu i 00:38.670 --> 00:42.810 zaczęło nam brakować adresów sieciowych w IPv4. 00:42.810 --> 00:46.860 Jest to znane jako wyczerpanie adresowe i jest to prawdziwa rzecz. 00:46.860 --> 00:49.260 W rzeczywistości w listopadzie 2019 00:49.260 --> 00:51.810 r. RIPE NCC, regionalny rejestr internetowy 00:51.810 --> 00:55.020 dla Europy, Azji Zachodniej i byłego ZSRR oraz 00:55.020 --> 00:56.160 NASA, wyczerpały 00:56.160 --> 00:59.130 już całą pulę adresów IPv4. 00:59.130 --> 01:01.770 Na szczęście jednak, Internet Engineering 01:01.770 --> 01:04.740 Task Force (IETF) już wcześniej zaczęła patrzeć 01:04.740 --> 01:06.600 w przyszłość i opracowała 01:06.600 --> 01:09.690 IPv6 jako standard już w 1995 roku, wydając dokument 01:09.690 --> 01:13.380 RFC, który dokumentował ich wizję IPv6, którą określili 01:13.380 --> 01:17.790 jako IP Next Generation lub IPNG. 01:17.790 --> 01:22.790 Teraz widać, że IPv6 jest w rzeczywistości ogromnym ulepszeniem w stosunku do IPv4 pod 01:22.860 --> 01:25.290 względem liczby dostępnych adresów. 01:25.290 --> 01:28.710 Zamiast 32-bitowego adresu, jak ma to miejsce w IPv4, 01:28.710 --> 01:32.100 IPv6 będzie używać 128-bitowego adresu. 01:32.100 --> 01:35.490 Zapewni to znacznie większą przestrzeń adresową. 01:35.490 --> 01:37.620 W rzeczywistości daje to możliwość 01:37.620 --> 01:41.430 uzyskania 340 miliardów adresów IP. 01:41.430 --> 01:42.930 To wystarczająca liczba adresów 01:42.930 --> 01:45.930 IP dla każdego mężczyzny, kobiety i dziecka na świecie. 01:45.930 --> 01:48.540 Jest to dwa do potęgi 128. 01:48.540 --> 01:51.300 W rzeczywistości istnieje wiele, wiele adresów IP dla każdego 01:51.300 --> 01:53.730 mężczyzny, kobiety i dziecka na planecie, ponieważ 01:53.730 --> 01:56.250 dostępnych jest tak wiele adresów IP. 01:56.250 --> 01:57.960 Teraz możesz się zastanawiać, 01:57.960 --> 02:01.230 hej, przeszliśmy z IPv4 na IPv6. 02:01.230 --> 02:03.090 Co się stało z wersją 5? 02:03.090 --> 02:05.370 Dlaczego przeskoczyliśmy od razu do wersji 6? 02:05.370 --> 02:09.180 Cóż, wersja 5 została stworzona, ale nigdy nie została w pełni przyjęta jako 02:09.180 --> 02:11.190 oficjalny protokół lub standard. 02:11.190 --> 02:13.350 Dlatego też nigdy nie trafił do produkcji. 02:13.350 --> 02:14.820 Zamiast tego wiele z tych koncepcji, 02:14.820 --> 02:16.350 które zostały opracowane w ramach wersji 02:16.350 --> 02:17.970 5, ponieważ był to protokół eksperymentalny, 02:17.970 --> 02:19.920 zostało następnie wprowadzonych do IPv6, gdy stał 02:19.920 --> 02:21.870 się on oficjalnym standardem. 02:21.870 --> 02:25.650 Porozmawiajmy więc o korzyściach płynących z IPv6. 02:25.650 --> 02:26.910 Jedną z największych korzyści 02:26.910 --> 02:28.890 jest znacznie większa przestrzeń adresowa 02:28.890 --> 02:31.350 dzięki 128-bitowym adresom. 02:31.350 --> 02:32.460 Oprócz tego, IPv6 zwiększył 02:32.460 --> 02:35.160 również wydajność naszych sieci poprzez usunięcie 02:35.160 --> 02:38.730 typu przepływu danych rozgłoszeniowych IPv4. 02:38.730 --> 02:41.250 Teraz IPv6 jest również bezpieczniejszy, 02:41.250 --> 02:44.010 ponieważ w standardzie IPv6 nie ma fragmentacji 02:44.010 --> 02:46.050 pakietów ani datagramów. 02:46.050 --> 02:48.150 W przeciwieństwie do IPv4, który zawiera MTU 02:48.150 --> 02:51.330 o określonym rozmiarze dla każdego pakietu, nie ma również maksymalnych 02:51.330 --> 02:54.870 jednostek transmisji dla wykrywania w ramach każdej sesji. 02:54.870 --> 02:57.030 W protokole IPv4, jeśli wysłałbym pakiet większy 02:57.030 --> 02:59.820 niż maksymalny rozmiar jednostki transmisji, zostałby 02:59.820 --> 03:01.080 on pofragmentowany i wysłany 03:01.080 --> 03:02.400 przez sieć. 03:02.400 --> 03:04.110 A kiedy dotrze do miejsca przeznaczenia, 03:04.110 --> 03:05.970 zostanie ponownie złożony i odczytany. 03:05.970 --> 03:07.650 W rzeczywistości stanowiło to zagrożenie dla bezpieczeństwa. 03:07.650 --> 03:09.540 Wymagało to również dodatkowego przetwarzania i mogło 03:09.540 --> 03:11.460 faktycznie spowolnić działanie sieci, ponieważ stało 03:11.460 --> 03:13.920 się to bardzo nieefektywnym sposobem robienia rzeczy w naszych nowoczesnych 03:13.920 --> 03:15.120 sieciach z wyższymi prędkościami 03:15.120 --> 03:17.070 połączenia internetowego. 03:17.070 --> 03:19.830 Tak więc w IPv6 zdecydowano się całkowicie 03:19.830 --> 03:21.900 wyeliminować fragmentację. 03:21.900 --> 03:24.480 Oprócz zapewnienia wszystkich tych nowych korzyści, 03:24.480 --> 03:26.970 twórcy IPv6 byli również bardzo sprytni i zdawali 03:26.970 --> 03:30.690 sobie sprawę, że aby IPv6 został w pełni przyjęty i zaakceptowany, 03:30.690 --> 03:33.630 musiałby być wstecznie kompatybilny z IPv4 i umożliwiać 03:33.630 --> 03:38.630 współistnienie zarówno IPv6, jak i IPv4 w tej samej sieci. 03:38.700 --> 03:41.490 W końcu już pod koniec lat 90-tych IPv6 był rozwijany 03:41.490 --> 03:43.950 i wypuszczany na rynek, a wiele sieci komputerowych 03:43.950 --> 03:45.270 było już uruchomionych 03:45.270 --> 03:47.490 na całym świecie. 03:47.490 --> 03:48.900 Nie byłoby więc możliwe, abyśmy 03:48.900 --> 03:51.960 po prostu zmienili wszystko w ciągu jednego dnia. 03:51.960 --> 03:53.490 Pomyśl o tym jak o obecnej migracji 03:53.490 --> 03:55.170 z pojazdów zasilanych gazem do pojazdów 03:55.170 --> 03:56.730 elektrycznych. 03:56.730 --> 03:58.920 Dzieje się tak przez cały 2020 03:58.920 --> 04:00.420 rok i do 2030 roku. 04:00.420 --> 04:02.970 Byłoby niemożliwe, gdybyśmy powiedzieli, że 04:02.970 --> 04:05.850 1 stycznia 2025 r. nikt nie będzie już mógł korzystać 04:05.850 --> 04:07.710 z pojazdów napędzanych gazem. 04:07.710 --> 04:08.700 Od tego dnia wszystkie z 04:08.700 --> 04:11.010 nich zostaną zastąpione pojazdami elektrycznymi. 04:11.010 --> 04:12.180 Gdyby rząd próbował to zrobić, 04:12.180 --> 04:14.160 prawdopodobnie miałby do czynienia z rewolucją, 04:14.160 --> 04:17.190 ponieważ tak wiele osób posiada już samochody napędzane gazem i wydało 04:17.190 --> 04:19.890 mnóstwo pieniędzy oraz zainwestowało w te samochody i infrastrukturę 04:19.890 --> 04:21.900 do ich obsługi. 04:21.900 --> 04:24.480 Z tego powodu nie zamierzamy po prostu zastąpić wszystkich samochodów 04:24.480 --> 04:26.250 napędzanych gazem z dnia na dzień. 04:26.250 --> 04:28.680 Zamiast tego nastąpi powolne przejście z zasilania 04:28.680 --> 04:32.130 gazowego na elektryczne, które potrwa do 2030, a może 2040 roku, ponieważ 04:32.130 --> 04:34.890 coraz więcej nowszych samochodów sprzedawanych na świecie 04:34.890 --> 04:37.050 będzie sprzedawanych jako elektryczne i przestaną 04:37.050 --> 04:39.390 sprzedawać pojazdy napędzane gazem. 04:39.390 --> 04:42.900 Cóż, dokładnie to samo dzieje się z IPv6. 04:42.900 --> 04:47.010 Tak więc IPv6 pozwala na współistnienie zarówno IPv4, jak i IPv6 w tych 04:47.010 --> 04:49.140 samych sieciach, a sprzęt obsługujący 04:49.140 --> 04:51.360 te sieci staje się znany jako podwójny 04:51.360 --> 04:53.370 stos, co oznacza po prostu, że mogą 04:53.370 --> 04:54.930 one jednocześnie uruchamiać 04:54.930 --> 04:58.200 zarówno protokoły IPv4, jak i protokoły IPv6 na tych samych 04:58.200 --> 05:01.080 urządzeniach sieciowych. 05:01.080 --> 05:04.410 W przypadku urządzeń z podwójnym stosem, jeśli klient obsługuje protokół IPv6, przełącznik 05:04.410 --> 05:06.960 routera wolałby korzystać z protokołu IPv6 i będzie komunikował 05:06.960 --> 05:08.760 się przy użyciu tej metody. 05:08.760 --> 05:11.370 Teraz, jeśli urządzenie nie jest w stanie obsługiwać protokołu 05:11.370 --> 05:13.080 IPv6, odwraca się i mówi: w porządku, 05:13.080 --> 05:16.380 będę z tobą rozmawiać przy użyciu starszego protokołu IPv4. 05:16.380 --> 05:18.390 W ten sposób nadal mogę cię wspierać. 05:18.390 --> 05:20.850 Inną stosowaną przez nas metodą jest tunelowanie. 05:20.850 --> 05:24.780 W tym przypadku protokół IPv6 będzie tunelowany przez urządzenie IPv4. 05:24.780 --> 05:27.150 Dzięki temu starsze routery IPv4 05:27.150 --> 05:29.580 mogą nadal przenosić ruch IPv6. 05:29.580 --> 05:31.710 IPv6 będzie zasadniczo tunelowany 05:31.710 --> 05:34.860 jako mechanizm enkapsulacji pakietów IPv6 w nagłówkach 05:34.860 --> 05:38.370 IPv4 i przenoszenia tych danych IPv6 przez routery IPv4 05:38.370 --> 05:40.320 i inną infrastrukturę, która 05:40.320 --> 05:42.480 już istnieje. 05:42.480 --> 05:44.640 Odbywa się to poprzez utworzenie tunelu punkt-punkt 05:44.640 --> 05:46.380 między źródłem a miejscem docelowym, a następnie 05:46.380 --> 05:48.450 enkapsulację tych informacji. 05:48.450 --> 05:51.630 Pozwala to odizolowanym klientom i serwerom IPv6 na komunikację bez 05:51.630 --> 05:53.310 konieczności aktualizacji wszystkich 05:53.310 --> 05:55.620 routerów i infrastruktury przełączników, które 05:55.620 --> 05:59.040 nadal używają protokołu IPv4, który może istnieć między nimi. 05:59.040 --> 06:02.880 Pewnego dnia możemy w końcu doczekać się całkowitego wycofania protokołu IPv4. 06:02.880 --> 06:05.070 Ale jak dotąd tak się nie stało. 06:05.070 --> 06:07.440 Osobiście nie wstrzymuję oddechu. 06:07.440 --> 06:08.670 Z niektórych przeczytanych 06:08.670 --> 06:11.160 przeze mnie artykułów wynika, że IPv4 pozostanie 06:11.160 --> 06:14.340 z nami co najmniej do 2040 roku, więc jako technik sieciowy będziesz 06:14.340 --> 06:17.430 musiał wiedzieć, jak pracować zarówno z IPv4, jak i IPv6 w 06:17.430 --> 06:20.640 dającej się przewidzieć przyszłości. 06:20.640 --> 06:24.120 Kolejną zaletą IPv6 jest uproszczony nagłówek. 06:24.120 --> 06:26.850 Tak więc zamiast tych 12 pól, które mieliśmy w IPv4, mamy 06:26.850 --> 06:29.430 tylko pięć pól w IPv6, co czyni go odchudzonym nagłówkiem, 06:29.430 --> 06:30.960 który jest o wiele bardziej wydajny 06:30.960 --> 06:33.630 do wysyłania przez nasze sieci. 06:33.630 --> 06:35.370 Być może zastanawiasz 06:35.370 --> 06:37.920 się, jak wygląda nagłówek IPv6? 06:37.920 --> 06:40.500 Pokażę ci to, ale pamiętaj, że nie musisz 06:40.500 --> 06:42.750 się tego uczyć na egzamin. 06:42.750 --> 06:44.940 Zamiast tego ma to na celu pokazanie różnych 06:44.940 --> 06:47.040 pól, które były w IPv4, który jest na górze, 06:47.040 --> 06:49.230 w porównaniu do IPv6, który jest na dole. 06:49.230 --> 06:51.240 Teraz widać, o ile prostsze 06:51.240 --> 06:54.450 jest IPv6 w porównaniu do IPv4. 06:54.450 --> 06:56.190 W porządku, wróćmy do kilku rzeczy, 06:56.190 --> 06:58.170 które musisz zrozumieć na egzaminie. 06:58.170 --> 07:01.590 Jak właściwie wygląda adres IPv6? 07:01.590 --> 07:04.590 Cóż, powiedziałem już, że ma 128 bitów długości, więc 07:04.590 --> 07:08.160 oznacza to, że miałby 128 jedynek lub zer, gdybyśmy zapisali 07:08.160 --> 07:09.600 go binarnie, a to wydaje mi 07:09.600 --> 07:11.910 się naprawdę złym pomysłem, więc nie będziemy 07:11.910 --> 07:13.410 tego robić. 07:13.410 --> 07:15.210 Teraz moglibyśmy użyć notacji dziesiętnej 07:15.210 --> 07:16.680 z kropkami, tak jak w IPv4, ale 07:16.680 --> 07:19.020 nadal będzie to dużo oktetów do zapisania, ponieważ 07:19.020 --> 07:23.670 potrzebowalibyśmy 16 oktetów do reprezentowania wszystkich 128 bitów. 07:23.670 --> 07:25.380 Aby rozwiązać ten problem, IETF 07:25.380 --> 07:27.360 zdecydował, że zamiast tego powinniśmy 07:27.360 --> 07:29.310 używać cyfr szesnastkowych. 07:29.310 --> 07:31.860 Liczba szesnastkowa to base-16, którą można 07:31.860 --> 07:33.150 pamiętać lub nie z lekcji 07:33.150 --> 07:34.980 algebry w szkole średniej. 07:34.980 --> 07:36.210 Teraz, w systemie szesnastkowym, 07:36.210 --> 07:38.760 każda cyfra szesnastkowa to w rzeczywistości cztery bity. 07:38.760 --> 07:41.250 Pozwoli nam to na reprezentowanie adresu IPv6 poprzez 07:41.250 --> 07:43.710 połączenie czterech cyfr szesnastkowych razem, aby 07:43.710 --> 07:45.780 utworzyć coś, co nazywamy segmentem. 07:45.780 --> 07:48.720 Segment będzie miał 16 bitów. 07:48.720 --> 07:51.030 Jest to reprezentowane przez te cztery cyfry szesnastkowe. 07:51.030 --> 07:52.440 Następnie dodamy dwukropek 07:52.440 --> 07:53.880 i będziemy dodawać segmenty, 07:53.880 --> 07:56.250 aż dojdziemy do 128 bitów, co zajmie osiem 07:56.250 --> 07:57.900 segmentów, z których każdy ma 07:57.900 --> 08:00.510 cztery cyfry szesnastkowe. 08:00.510 --> 08:03.510 Daje mi to w sumie 32 cyfry szesnastkowe, 08:03.510 --> 08:05.460 co nadal jest dość długie. 08:05.460 --> 08:09.330 Przy 128 bitach reprezentowanych w adresie IPv6 oznacza to, że nie 08:09.330 --> 08:12.810 będziemy mieć więcej niż 32 cyfry szesnastkowe wewnątrz wszystkich 08:12.810 --> 08:14.700 tych segmentów. 08:14.700 --> 08:18.150 Dlaczego powiedziałem, że łączna długość tych ośmiu segmentów 08:18.150 --> 08:20.250 nie może przekraczać 32 cyfr? 08:20.250 --> 08:22.800 Dlaczego nie miałyby to być po prostu 32 cyfry 08:22.800 --> 08:25.710 szesnastkowe, ponieważ 32 cyfry razy cztery bity 08:25.710 --> 08:28.290 na cyfrę dałyby nam 128 bitów? 08:28.290 --> 08:31.320 Dzieje się tak dlatego, że IPv6 pozwala nam używać 08:31.320 --> 08:33.450 skrótu, aby móc uprościć nasze 08:33.450 --> 08:35.880 bardzo długie adresy IPv6. 08:35.880 --> 08:37.980 Zasady stenografii są naprawdę ważne, ponieważ 08:37.980 --> 08:40.650 można na nich znaleźć pytania egzaminacyjne. 08:40.650 --> 08:43.020 Jeśli więc masz cztery zera w segmencie, możesz 08:43.020 --> 08:45.360 zamiast tego wstawić jedno zero i zrezygnować 08:45.360 --> 08:47.310 z zer początkowych. 08:47.310 --> 08:50.790 Załóżmy na przykład, że mam naprawdę długi 08:50.790 --> 08:55.790 adres IPv6 2018:0000:0000:0000:0000:0000:4815:54ae. 09:04.470 --> 09:05.820 Korzystając z prostej reguły, 09:05.820 --> 09:08.490 mogę zastąpić wszystkie te segmenty, które mają wiele zer, 09:08.490 --> 09:09.810 pojedynczym zerem. 09:09.810 --> 09:14.810 To dałoby mi 2018:0:0:0:0:4815:54ae. 09:19.590 --> 09:22.680 W porządku, to zmniejszyło moją liczbę cyfr szesnastkowych 09:22.680 --> 09:26.790 z 32 do zaledwie 17, więc jest o połowę krótsza. 09:26.790 --> 09:29.520 Jest coraz lepiej, ale nie zamierzam na tym poprzestać. 09:29.520 --> 09:30.710 Jest jeszcze jedna zasada, 09:30.710 --> 09:33.000 której mogę użyć w świecie skrótów IPv6. 09:33.000 --> 09:35.280 Ta reguła mówi, że jeśli istnieje wiele segmentów, 09:35.280 --> 09:36.840 w których wszystkie mają zera i 09:36.840 --> 09:39.420 żadne inne cyfry szesnastkowe nie są tam reprezentowane, 09:39.420 --> 09:42.150 mogę podsumować to za pomocą podwójnego dwukropka i usunąć 09:42.150 --> 09:44.160 wszystkie te zera. 09:44.160 --> 09:45.420 Ta reguła jest wyjątkowa, 09:45.420 --> 09:48.540 ponieważ podwójny dwukropek można wykonać tylko 09:48.540 --> 09:50.460 raz w adresie IPv6. 09:50.460 --> 09:52.530 Korzystając z reguły podwójnego 09:52.530 --> 09:57.530 dwukropka, mogę podsumować 2018:0:0:0:0:4815:54ae, usuwając wszystkie 10:00.750 --> 10:03.270 te pięć zestawów zer i zastępując je podwójnym 10:03.270 --> 10:04.950 dwukropkiem, uzyskując 10:04.950 --> 10:07.450 2018::4815::54ae. 10:10.290 --> 10:13.020 Tak więc przeszedłem z 32 cyfr szesnastkowych 10:13.020 --> 10:14.910 do 17 cyfr szesnastkowych, 10:14.910 --> 10:17.160 a teraz z 17 cyfr aż do 12 cyfr, znacznie 10:17.160 --> 10:19.080 mniejszych, znacznie łatwiejszych 10:19.080 --> 10:21.690 w pracy. 10:21.690 --> 10:24.240 Możesz zobaczyć, jak ten skrót jest naprawdę pomocny. 10:24.240 --> 10:27.150 Jak więc rozpoznać adres IPv6 w porównaniu 10:27.150 --> 10:28.950 z adresem IPv4? 10:28.950 --> 10:32.130 Pierwszym sposobem jest przyjrzenie się, czym jest IPv4. 10:32.130 --> 10:35.400 Protokół IPv4 zawsze będzie używał notacji dziesiętnej z kropkami, 10:35.400 --> 10:36.990 wykorzystując cztery oktety. 10:36.990 --> 10:38.490 Z drugiej strony, IPv6 będzie używać 10:38.490 --> 10:40.530 dwukropków między liczbami i będzie zapisywany 10:40.530 --> 10:42.450 w systemie szesnastkowym. 10:42.450 --> 10:44.280 W porządku, teraz jednym z pytań, które 10:44.280 --> 10:45.810 możesz zobaczyć w dniu testu, 10:45.810 --> 10:49.080 jest zidentyfikowanie adresu IPv6, gdy go zobaczysz. 10:49.080 --> 10:51.180 Na przykład, możesz otrzymać pytanie typu: 10:51.180 --> 10:53.700 Który z poniższych adresów jest adresem IPv6? 10:53.700 --> 10:55.410 To będzie słuszne pytanie. 10:55.410 --> 10:59.280 Otrzymasz kilka opcji, takich jak 192. 168. 1. 1, o którym wiemy, 10:59.280 --> 11:01.830 że nim nie jest, ponieważ jest to adres IPv4. 11:01.830 --> 11:06.830 Otrzymasz 12:34:56:78:90:AB 11:07.590 --> 11:12.000 lub 1234::5678::90AB. 11:12.000 --> 11:15.120 Chwileczkę, te dwie ostatnie rzeczy, które właśnie powiedziałem, 11:15.120 --> 11:17.010 są naprawdę podobne, prawda? 11:17.010 --> 11:20.310 Tak, ale tylko jeden z nich jest prawidłowym adresem IPv6. 11:20.310 --> 11:21.630 Czy wiesz, który to? 11:21.630 --> 11:24.000 Ponieważ większość studentów jest tutaj zdezorientowana. 11:24.000 --> 11:28.020 Druga opcja nie jest w rzeczywistości adresem IPv6. 11:28.020 --> 11:29.820 Zamiast tego jest to adres MAC. 11:29.820 --> 11:31.260 Pamiętaj, że adresy MAC, które 11:31.260 --> 11:33.060 są adresami fizycznymi warstwy 2, 11:33.060 --> 11:35.580 zawsze składają się z 12 cyfr szesnastkowych oddzielonych 11:35.580 --> 11:37.230 dwukropkami. 11:37.230 --> 11:38.370 Zazwyczaj będą one zapisywane 11:38.370 --> 11:40.410 jako sześć grup po dwie cyfry, a każda z nich 11:40.410 --> 11:43.200 będzie oddzielona pojedynczym dwukropkiem. 11:43.200 --> 11:46.080 Z drugiej strony adres IPv6 powinien być zawsze zapisywany 11:46.080 --> 11:48.120 w segmentach po cztery cyfry każdy i zawsze 11:48.120 --> 11:50.580 powinien mieć 16 segmentów, chyba że widzisz 11:50.580 --> 11:52.500 podwójny dwukropek. 11:52.500 --> 11:55.080 W tym przykładzie mamy podwójny dwukropek między 11:55.080 --> 11:58.020 pierwszym i drugim segmentem w naszej trzeciej opcji. 11:58.020 --> 12:00.840 Jest to więc dobry skrót, którego możemy użyć i 12:00.840 --> 12:03.450 identyfikujemy, że był to adres IPv6, ponieważ 12:03.450 --> 12:05.130 usunęliśmy wszystkie zera między 12:05.130 --> 12:08.520 pierwszym a drugim segmentem w tym adresie. 12:08.520 --> 12:09.960 Jeśli więc policzysz coś, 12:09.960 --> 12:11.790 co wygląda jak adres IPv6 i ma 12, 12:11.790 --> 12:15.480 dokładnie 12 cyfr szesnastkowych oddzielonych pojedynczymi 12:15.480 --> 12:17.040 dwukropkami i nigdzie nie 12:17.040 --> 12:18.840 widzisz podwójnego dwukropka, 12:18.840 --> 12:22.140 jest to adres MAC, a nie adres IPv6. 12:22.140 --> 12:24.180 W przeciwnym razie, jeśli wygląda 12:24.180 --> 12:25.860 coś takiego i zawiera cyfry 12:25.860 --> 12:29.190 szesnastkowe, będzie to adres IPv6 w dniu egzaminu. 12:29.190 --> 12:31.440 Na egzaminie wystarczy być w stanie rozpoznać, 12:31.440 --> 12:33.540 jak wygląda adres IPv6 i powinieneś być 12:33.540 --> 12:35.790 w stanie go podsumować, usuwając zera i konsolidując 12:35.790 --> 12:39.960 je za pomocą sztuczki z podwójnym dwukropkiem. 12:39.960 --> 12:41.490 Jeśli potrafisz zrobić te dwie 12:41.490 --> 12:45.000 rzeczy, w dniu egzaminu poradzisz sobie z adresowaniem IPv6. 12:45.000 --> 12:47.280 Jeśli chodzi o adresowanie IPv6, istnieją 12:47.280 --> 12:50.100 trzy różne typy adresów, których można używać: 12:50.100 --> 12:52.220 adresy unicast, adresy multicast 12:52.220 --> 12:54.210 i adresy anycast. 12:54.210 --> 12:56.640 Jedną z interesujących rzeczy w IPv6, która 12:56.640 --> 12:59.040 naprawdę odróżnia go od IPv4, jest to, że 12:59.040 --> 13:01.830 możemy przypisać wiele adresów IPv6 do pojedynczego 13:01.830 --> 13:03.900 interfejsu na kliencie. 13:03.900 --> 13:05.730 Przypisania te mogą być mieszanką 13:05.730 --> 13:07.680 trzech różnych typów: unicast, 13:07.680 --> 13:10.290 multicast i anycast. 13:10.290 --> 13:13.140 Tak więc nawet jeśli masz tylko jedną kartę sieciową 13:13.140 --> 13:14.910 na stacji roboczej lub laptopie, 13:14.910 --> 13:17.430 możesz mieć wiele adresów IPv6 i różnych 13:17.430 --> 13:19.860 typów adresów IPv6 przypisanych do tej 13:19.860 --> 13:22.140 jednej karty. 13:22.140 --> 13:23.850 Adresy Unicast będą używane do identyfikacji 13:23.850 --> 13:25.950 pojedynczego interfejsu. 13:25.950 --> 13:28.950 Są one podzielone na adresy unicastowe routowane globalnie 13:28.950 --> 13:30.930 i adresy lokalne łącza. 13:30.930 --> 13:32.760 Adres unicastowy routowany globalnie 13:32.760 --> 13:36.150 jest podobny do tego, co mamy jako adres publiczny w IPv4 13:36.150 --> 13:39.600 przy użyciu adresów unicastowych klasy A, B i C. 13:39.600 --> 13:42.840 Teraz, w IPv6, globalnie routowany adres unicastowy 13:42.840 --> 13:44.220 zawsze zaczyna się 13:44.220 --> 13:49.050 od pierwszego segmentu zawierającego 2000-3999. 13:49.050 --> 13:52.740 Teraz, jeśli widzisz 2000-3999 jako pierwszy segment, oznacza 13:52.740 --> 13:55.770 to, że jest to adres unicast routowany globalnie. 13:55.770 --> 13:58.050 Na przykład adres IPv6 13:58.050 --> 14:14.010 2584:0db8:8583:1234:5678:882e:0370:7334 byłby routowany globalnie jako adres unicastowy, ponieważ jego pierwszy segment zawiera 14:14.010 --> 14:17.070 2584, który znajduje się między 14:17.070 --> 14:20.670 2000 a 3999. 14:20.670 --> 14:22.650 Z drugiej strony, adres lokalny łącza, 14:22.650 --> 14:24.690 zwany również adresem do użytku lokalnego, 14:24.690 --> 14:28.020 jest używany podobnie jak prywatny adres IP w IPv4. 14:28.020 --> 14:29.970 Adres lokalny łącza w IPv6 14:29.970 --> 14:32.097 może być używany tylko w sieci 14:32.097 --> 14:36.840 lokalnej i zawsze zaczyna się od FE80 jako pierwszego segmentu 14:36.840 --> 14:38.940 w adresie IPv6. 14:38.940 --> 14:41.760 Teraz, za każdym razem, gdy system IPv6 zostanie uruchomiony, 14:41.760 --> 14:44.100 faktycznie utworzy adres lokalny łącza dla każdego 14:44.100 --> 14:47.070 interfejsu IPv6 w tym systemie, nawet jeśli adres routowalny 14:47.070 --> 14:48.720 globalnie został już skonfigurowany 14:48.720 --> 14:50.190 ręcznie lub uzyskany za pomocą 14:50.190 --> 14:53.700 protokołu konfiguracyjnego, takiego jak DHCP. 14:53.700 --> 14:56.340 Aby to zrobić, użyje czegoś znanego jako SLAAC, 14:56.340 --> 15:00.840 bezstanowa automatyczna konfiguracja adresu lub S-L-A-A-C. 15:00.840 --> 15:02.610 Dzięki bezstanowej autokonfiguracji 15:02.610 --> 15:04.680 host nie musi uzyskiwać adresów ani innych 15:04.680 --> 15:06.210 informacji konfiguracyjnych ze 15:06.210 --> 15:08.880 scentralizowanego serwera, takiego jak DHCP. 15:08.880 --> 15:11.640 Zamiast tego może niezależnie przypisać sobie adres 15:11.640 --> 15:13.050 lokalny łącza, przetestować 15:13.050 --> 15:15.420 unikalność tego adresu lokalnego łącza, przypisać 15:15.420 --> 15:17.430 sobie adres lokalny łącza, skontaktować 15:17.430 --> 15:22.680 się z routerem i wskazać węzłowi, jak kontynuować autokonfigurację. 15:22.680 --> 15:25.770 Może nawet skonfigurować globalny adres unicast, 15:25.770 --> 15:27.090 którego chce używać. 15:27.090 --> 15:29.520 Wrócimy do tej koncepcji za kilka minut, gdy 15:29.520 --> 15:31.110 zagłębimy się w nią nieco głębiej, 15:31.110 --> 15:34.080 gdy zaczniemy mówić o EUI-64 i protokole wykrywania sąsiadów, 15:34.080 --> 15:35.580 ponieważ oba te procesy są używane 15:35.580 --> 15:37.650 z protokołem bezstanowej automatycznej 15:37.650 --> 15:41.580 konfiguracji adresów znanym jako SLAAC. 15:41.580 --> 15:43.680 Następnie mamy adresy multiemisji. 15:43.680 --> 15:45.360 Obecnie adresy multicastowe są używane 15:45.360 --> 15:47.100 do identyfikacji grupy interfejsów, dzięki 15:47.100 --> 15:49.710 czemu pakiet może zostać wysłany na adres multicastowy, a następnie 15:49.710 --> 15:52.680 dostarczony do wszystkich interfejsów w grupie. 15:52.680 --> 15:56.550 W IPv6 adres multicastowy zawsze będzie zawierał FF jako dwie 15:56.550 --> 15:59.460 pierwsze cyfry w pierwszym segmencie. 15:59.460 --> 16:02.280 Jeśli widzisz FF na początku adresu IPv6, 16:02.280 --> 16:04.800 pamiętaj o jego multiemisji. 16:04.800 --> 16:06.330 Ostatnim typem adresu 16:06.330 --> 16:08.700 jest adres anycast. 16:08.700 --> 16:11.610 Adresy Anycast są używane do identyfikacji zestawu interfejsów, dzięki 16:11.610 --> 16:14.400 czemu pakiet może zostać wysłany do dowolnego członka zestawu. 16:14.400 --> 16:16.320 Adresy anycast są w rzeczywistości przydzielane 16:16.320 --> 16:18.060 z przestrzeni adresowej unicast. 16:18.060 --> 16:19.620 Tak więc tak naprawdę nie ma 16:19.620 --> 16:22.710 sposobu, aby określić, czy adres IPv6 jest unicastem 16:22.710 --> 16:25.410 czy anycastem, patrząc tylko na adres IPv6. 16:25.410 --> 16:28.050 Teraz, gdy patrzysz na multiemisję lub link-local, masz 16:28.050 --> 16:29.790 bardzo łatwy sposób, aby to zrobić, 16:29.790 --> 16:31.440 ale nie masz łatwego sposobu na określenie 16:31.440 --> 16:33.870 unicastu w porównaniu z anycastem. 16:33.870 --> 16:35.010 W porządku, wróćmy i porozmawiajmy 16:35.010 --> 16:36.990 trochę więcej o SLAAC, procesie automatycznej 16:36.990 --> 16:40.140 konfiguracji adresów bezstanowych. 16:40.140 --> 16:42.090 Jak już wspomniałem, w IPv6 istnieje 16:42.090 --> 16:45.120 proces automatycznej konfiguracji znany jako SLAAC, którego 16:45.120 --> 16:46.980 używamy do wykrywania bieżącej sieci, 16:46.980 --> 16:48.570 w której znajduje się interfejs, 16:48.570 --> 16:51.360 a następnie pozwalamy mu wybrać własny identyfikator 16:51.360 --> 16:56.360 hosta na podstawie adresu MAC przy użyciu procesu znanego jako EUI-64. 16:56.550 --> 17:01.410 Teraz ten proces EUI-64 lub Extended Unique Identifier pozwoli hostowi 17:01.410 --> 17:03.450 przypisać sobie unikalny 64-bitowy 17:03.450 --> 17:07.967 identyfikator interfejsu IPv6 o nazwie EUI-64. 17:09.180 --> 17:12.000 Teraz ten adres w formacie EUI-64 jest uzyskiwany 17:12.000 --> 17:15.480 przy użyciu 48-bitowego adresu MAC interfejsu. 17:15.480 --> 17:19.260 Adres MAC jest najpierw dzielony na dwie 24-bitowe części. 17:19.260 --> 17:22.890 Pierwsza połowa adresu MAC będzie zawierać OUI, czyli Organizational 17:22.890 --> 17:25.170 Unique Identifier. 17:25.170 --> 17:26.850 Druga połowa będzie zawierać konkretną 17:26.850 --> 17:29.010 kartę interfejsu sieciowego. 17:29.010 --> 17:30.780 Pomiędzy nimi umieścimy 17:30.780 --> 17:35.730 16-bitową wartość szesnastkową FFFE. 17:35.730 --> 17:39.990 W ten sposób mogę wziąć 24 bity, 16 bitów i 24 bity i 17:39.990 --> 17:44.760 połączyć je razem, aby uzyskać 64-bitowy adres EUI. 17:44.760 --> 17:47.340 Daje to 64 bity, które będą potrzebne do identyfikacji 17:47.340 --> 17:49.860 interfejsu w tej sieci. 17:49.860 --> 17:52.320 Następnie interfejs użyje automatycznego 17:52.320 --> 17:53.910 wykrywania, aby określić sieć, 17:53.910 --> 17:57.030 w której się znajduje i dodać część sieciową adresu IPv6, 17:57.030 --> 18:00.960 która będzie pierwszymi 64 bitami wewnątrz naszych adresów. 18:00.960 --> 18:02.940 Teraz umieścimy te pierwsze 64 bity 18:02.940 --> 18:05.580 reprezentujące sieć przed 64 bitami z adresu 18:05.580 --> 18:09.390 EUI-64, który utworzyliśmy z naszego adresu MAC, aby utworzyć 18:09.390 --> 18:13.050 globalnie routowalny adres IPv6 unicast, którego możemy 18:13.050 --> 18:14.550 teraz użyć. 18:14.550 --> 18:16.890 Możesz więc zobaczyć, jak wszystko to działa razem, 18:16.890 --> 18:18.180 używając tego adresu MAC do 18:18.180 --> 18:20.700 utworzenia adresu routowalnego globalnie. 18:20.700 --> 18:24.180 Teraz DHCP może być również używany w IPv6, jeśli 18:24.180 --> 18:25.560 wolisz go używać. 18:25.560 --> 18:29.520 Jeśli tak, będziesz musiał użyć protokołu DHCPv6. 18:29.520 --> 18:30.930 Pozwoliłoby to na automatyczne 18:30.930 --> 18:34.650 przypisywanie rzeczy przez DHCP z serwera DHCPv6. 18:34.650 --> 18:38.520 Ponieważ jednak proces automatycznej konfiguracji z EUI-64 jest 18:38.520 --> 18:41.430 już domyślnie wbudowany w protokół IPv6, nie ma potrzeby 18:41.430 --> 18:43.230 korzystania z DHCPv6. 18:44.280 --> 18:47.580 Ale jeśli chcesz użyć DHCPv6, możesz to zrobić, a to pozwoli ci 18:47.580 --> 18:48.870 przypisać adresy, które 18:48.870 --> 18:51.360 każdy interfejs otrzyma, zamiast pozwalać im 18:51.360 --> 18:52.500 na korzystanie z protokołu 18:52.500 --> 18:55.170 automatycznej konfiguracji SLAAC. 18:55.170 --> 18:58.560 Jak już wspomniałem, IPv6 domyślnie wybiera swój własny 18:58.560 --> 19:00.930 adres w oparciu o adres MAC, a następnie korzysta 19:00.930 --> 19:03.480 z protokołu NDP lub protokołu wykrywania sąsiadów, 19:03.480 --> 19:05.310 aby dowiedzieć się o innych adresach 19:05.310 --> 19:09.990 warstwy 2 w sieci w oparciu o ich adresy MAC, a następnie wybiera swój własny identyfikator 19:09.990 --> 19:12.630 hosta. 19:12.630 --> 19:15.630 Na egzaminie nie trzeba dogłębnie znać protokołu NDP, 19:15.630 --> 19:17.850 ale należy zrozumieć, że NDP, protokół 19:17.850 --> 19:20.847 wykrywania sąsiadów, jest używany w IPv6 i przejmuje 19:20.847 --> 19:22.410 wiele funkcji z reklam routerów 19:22.410 --> 19:24.420 i wykrywania sąsiadów i obsługuje je 19:24.420 --> 19:25.683 za Ciebie.