Ma az IPv6 protokollal fogunk foglalkozni. A korábbi CCNA kurzus verziója nem követelte meg a protokoll részletes megismerését, de a harmadik, 200-125 verzióban a mélyreható tanulmányozása kötelező a vizsga letételéhez. Az IPv6 protokollt már régen kidolgozták, de hosszú ideig nem terjedt el széles körben. Nagyon fontos az internet jövőbeli fejlődése szempontjából, mivel a széles körben használt IPv4 protokoll hátrányainak kiküszöbölésére készült.
Mivel az IPv6 protokoll meglehetősen terjedelmes téma, két videó leckére osztottam. Az első napon az alapfogalmakkal foglalkozunk, a második napon pedig az IPv6 protokoll szerinti IP-címek beállítását vizsgáljuk a Cisco eszközökön. Ma, ahogy már megszokhatták, három témát fogunk átvenni: az IPv6 szükségessége, az IPv6 címek formátuma és az IPv6 címek típusai.
Eddig az óráink során v4 protokoll szerinti IP-címeket használtunk, és Önök hozzászoktak, hogy ezek eléggé egyszerűen néznek ki. Amikor ezt a dián látható címet látták, pontosan tudták, miről van szó.
Azonban az v6 IP-címek teljesen más formában jelennek meg. Ha nem ismeri az IP-címek létrehozásának elveit ebben az internet protokoll verzióban, először is meg fogja lepni, hogy az ilyen típusú IP-cím nagyon sok helyet foglal el. A negyedik verzióban csupán 4 tizedes számunk volt, ami egyszerűsíti a dolgokat, de képzelje el, hogy Mr. X-nek meg kell adnia az új IP-címét, ami a 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
De ne aggódjon – a videó leckénk végére sokkal jobb helyzetben fogunk állni. Először nézzük meg, miért vált szükségessé az IPv6 használata.
Ma a legtöbb ember IPv4-et használ, és elégedettek vele. Miért volt szükség az új verzióra? Először is, a negyedik verzió IP-címei 32 bitből állnak. Ez lehetővé teszi, hogy körülbelül 4 milliárd címet hozzunk létre az interneten, vagyis az IP-címek pontos száma 232. Amikor az IPv4-et létrehozták, a fejlesztők úgy gondolták, hogy ez a szám bőven elegendő. Ha emlékszel, ennek a verziónak a címei 5 osztályra oszlanak: a működő A, B, C osztályok és a fenntartott D (multicast) és E (kutatási) osztályok. Így bár a működő IP-címek száma mindössze 75%-át tette ki a 4 milliárdnak, a protokoll létrehozói biztosak voltak benne, hogy elegendő lesz minden ember számára. Azonban az internet gyors fejlődésével évről évre egyre inkább érzékelhetővé vált a szabad IP-címek hiánya, és ha nem lett volna a NAT technológia használata, az IPv4 szabad címei már rég elfogytak volna. Valójában a NAT lett ennek az internet protokollnak a megmentője. Ezért merült fel az új verzió, amely mentes volt a negyedik változat hiányosságaitól. Kérdezheted, miért ugrottunk a negyedik verzióról egyenesen a hatodikra. Ez azért van, mert az 5-ös verzió, akárcsak az 1, 2 és 3, kísérleti volt.
Tehát az IPv6 címek 128 bites címzési teret használnak. Mit gondol, hányszorosára nőtt a lehetséges IP-címek száma? Valószínűleg azt mondaná: „4-szer!”. De ez nem így van, mert 234 már 4-szer nagyobb, mint 232. Így a 2^128 értéke hihetetlenül nagy – 340282366920938463463374607431768211456. Ennyi IP-cím áll rendelkezésre az IPv6 protokollon. Ez azt jelenti, hogy IP-címet adhat bárminek, aminek csak szeretne: az autójának, telefonjának, okosórájának. A modern embernek lehet laptopja, több okostelefonja, okosórája, okos otthona – tévé, amely csatlakozik az internethez, internetkapcsolattal rendelkező mosógép, egy egész ház, amely az internethez kapcsolódik. Ez a címek mennyisége lehetővé teszi az „internet dolgai” koncepcióját, amelyet a Cisco támogat. Ez azt jelenti, hogy az életében minden dolog kapcsolódik az internethez, és mindegyiknek szüksége van saját IP-címére. Az IPv6 segítségével ez lehetséges! Minden ember a Földön milliókat használhat ennek a verziónak az IP-címeiből, és még mindig túl sok marad szabadon. Nem tudjuk megjósolni, hogyan fejlődnek a technológiák, de reméljük, hogy az emberiség nem jut el arra a pontra, hogy a Földön csak egy számítógép marad. Feltételezhetjük, hogy az IPv6 még hosszú ideig fennmarad. Nézzük meg, mit jelent a hatodik verziójú IP-cím formátuma.
Ezek a címek 8 csoport hexadecimális számok formájában jelennek meg. Ez azt jelenti, hogy a cím minden karaktere 4 bit hosszú, így minden 4 karakterből álló csoport 16 bitből áll, a cím hossza pedig 128 bit. Minden 4 karakterből álló csoportot kettős pontosvessző választ el a következő csoporttól, ellentétben az IPv4 címekkel, ahol a csoportokat pontok választották el, mivel a pont a számok tízes formájú reprezentációja. Mivel nehéz megjegyezni egy ilyen címet, több szabály is létezik a rövidítésére. Az első szabály kimondja, hogy a kizárólag nullákból álló csoportokat kettős ponttal lehet helyettesíteni. Ezt a műveletet minden IP-címen csak egyszer lehet végrehajtani. Nézzük meg, mit jelent ez.
Ahogy látja, a bemutatott példában a cím három csoportot tartalmaz négy nullával. A kettőspontok összesen 2, amelyek ezeket a csoportokat elválasztják: 0000:0000:0000. Így, ha dupla kettőspontot :: használunk, az azt jelenti, hogy ezen a ponton a címben nullacsoportok helyezkednek el. Hogyan tudjuk meg, hány nullacsoportot jelöl ez a dupla kettőspont? Ha megnézzük a cím tömörített formáját, 5 csoportot számolhatunk, mindegyik 4 karakterből áll. De mivel tudjuk, hogy a teljes cím 8 csoportból áll, a dupla kettőspont 3 gruppot jelent, mindegyik négy nullából. Ez a tömörített címzés első szabálya.
A második szabály kimondja, hogy elhagyhatjuk a vezető nullákat minden karaktercsoportban. Például a cím teljes formájának 6. csoportja 04FF, míg a rövidített forma 4FF, mert elhagytuk a vezető nullát. Így a 4FF írásmód nem más, mint 04FF.
Ezeket a szabályokat használva bármilyen IP-címet le tudunk rövidíteni. Azonban még a rövidítés után sem tűnik valóban rövidnek ez a cím. Később megnézzük, mit tehetünk ezzel, addig is egyszerűen jegyezze meg ezeket a 2 szabályt.
Nézzük meg, mit jelentenek az IPv4 és IPv6 fejlécek.
Ez a kép, amelyet az Internetről szereztem, nagyon jól magyarázza a két fejléc közötti különbséget. Ahogy látja, az IPv4 cím fejléc sokkal bonyolultabb és több információt tartalmaz, mint az IPv6 fejléc. Ha a fejléc bonyolult, akkor az útválasztó több időt tölt a feldolgozásával a route döntés meghozatala során, ezért a NULL IPv6 címek esetén az útválasztók hatékonyabban működnek. Ezért az IPv6 sokkal jobb, mint az IPv4.
Az IPv4 fejléc hossza 0-tól 31-ig terjedhet, és 32 bitet foglal el. A legutolsó Options és Padding sor figyelembevételével a 4-es verziójú IP cím 20 bájt méretű, vagyis a minimum mérete 20 bájt. A hatos verzió címe nem rendelkezik minimális mérettel, és a cím fix hossza 40 bájt.
Az IPv4 fejlécében először a verzió szerepel, majd az IHL fejléc hosszát adják meg. Alapértelmezés szerint ez 20 bájt, de ha a fejlécben további információk kerülnek megadásra az Options segítségével, akkor a hossza nagyobb is lehet. Ha Wiresharkot használunk, akkor elolvashatjuk a Version értékét, amely 4, valamint az IHL értékét, amely 5, ami azt jelenti, hogy öt függőleges blokk van, mindegyik 4 bájtos (32 bit), a Options blokkot nem számítva.
A Szolgáltatás típusa (Type of Service) megmutatja a csomag jellegét - például lehet hangcsomag vagy adatcsomag, mivel a hangforgalom prioritást élvez a többi forgalomfajta felett. Röviden, ez a mező a forgalom prioritását jelzi. Az Összhossz (Total Length) az 20 bájt hosszú fejléc és a hasznos teher hosszának összegét képviseli, amely a továbbított adatokat jelenti. Ha ez 50 bájt, akkor az összhossz 70 bájt lesz. A Csomag azonosító (Identification) a csomag integritásának ellenőrzésére szolgál a Fejléc ellenőrző összeg (Header Checksum) paraméter felhasználásával. Ha a csomag 5 részre van bontva, mindegyiknek azonos azonosítónak kell lennie - a Rész eltólás (Fragment Offset), amely 0 és 4 között lehet, úgy, hogy minden csomagrész azonos eltúlás-értékkel rendelkezzen. A zászlók azt jelzik, hogy megengedett-e a részletek eltúlása. Ha nem szeretné, hogy az adatok fragmentálódjanak, akkor beállítja a DF zászlót - ne fragmentáljon. Létezik egy MF zászló is - több rész. Ez azt jelenti, hogy ha az első csomag 5 részre van fragmentálva, a második csomag esetén 0 értéket állítanak be, jelezve: több fragmentum nem! Ily módon az első csomag utolsó részét 4-es értékkel jelölik, így a fogadó eszköz könnyen összeállíthatja a csomagot, tehát alkalmazhatja a de-fragmentálást.
Figyeljen a színekre, amelyeket ezen a dián használtak. A vörös színű mezők az IPv6 fejlécéből kivett mezőket jelölik. A kék színű paraméterek az átalakított formában kerültek át a negyedik verzióból a hatodik verzióba. A sárga mezők mindkét verzióban változatlanok maradtak. A zöld színű mező pedig csak az IPv6-ban jelent meg először.
Az Identification, Flags, Fragment Offset és Header Checksum mezőket kihagyták, mivel a modern adatátviteli környezetben nem fordul elő fragmentálás, és a checksum ellenőrzése nem szükséges. Sok évvel ezelőtt, lassú adatátvitel esetén, a fragmentálás gyakori jelenség volt, de ma már az IEEE 802.3 szabvány szerint használt 1500 bájtos MTU Ethernet elterjedt, és a fragmentálás már nem történik meg.
A TTL, vagyis a csomag élettartama egy visszaszámláló – amikor az élettartam eléri a 0-t, a csomagot eldobják. Valójában ez a legnagyobb számú ugrás, amit egy adott hálózatban megtehetünk. A Protocol mező mutatja, hogy melyik protokoll, TCP vagy UDP, használatos a hálózatban.
A Header Checksum elavult paraméter, ezért kihagyták az új protokoll verzióból. Ezután a 32 bites forrás és a 32 bites cél cím mezők találhatók. Ha van információnk az Options mezőben, akkor az IHL értéke 5-ről 6-ra változik, jelezve, hogy a fejléces mezőben további információ található.
Az IPv6 fejlécben is használják a Version mezőt, míg a Traffic Class megfelel az IPv4 fejléc Type of Service mezőjének. A Flow Label hasonló a Traffic Class-hoz, és a homogén csomagáramok egyszerűsített irányítására szolgál. A Payload Length a terhelés hosszát jelenti, vagyis az adatok mező méretét, amely a fejléc alatti mezőben található. A fejléc hossza 40 bájt, ami állandó, ezért máshol nem említik.
A Next Header mező megmutatja, hogy a következő csomagnak milyen típusú fejléce lesz. Ez egy nagyon hasznos funkció, amely meghatározza a következő szállító protokoll típusát – TCP, UDP stb., és amely nagy keresletet jelent a későbbi adatátviteli technológiákban. Még ha saját protokollt is használ, akkor is megtudhatja, hogy mi lesz a következő protokoll.
A max lépéseket, vagyis a Hop Limit-et az IPv4 TTL-jének felel meg, ez egy mechanizmus a routing ciklusának megakadályozására. Ezután a 128 bites forrás és a 128 bites cél cím mezők találhatók. Az egész fejléc 40 bájt méretű. Ahogy mondtam, az IPv6 sokkal egyszerűbb, mint az IPv4, és sokkal hatékonyabb a routerek számára a routing döntések meghozatalakor.
Nézzük meg az IPv6 címek típusait. Tudjuk, hogy mi az unicast – ez egy irányított adatátvitel, amikor egyik eszköz közvetlenül kapcsolódik a másikhoz, és mindkét eszköz csak egymással tud kommunikálni. A multicast széleskörű adatátvitelt jelent, azt jelenti, hogy több eszköz egyszerre tud egyetlen eszközhöz csatlakozni, amely viszont egyszerre tud kapcsolatot tartani több eszközzel. Ebből a szempontból a multicast hasonlít a rádióállomásra, amelynek jelei mindenütt terjednek. Ha egy adott csatornát szeretne hallani, akkor be kell állítania a rádióját egy adott frekvenciára. Ha emlékszik a RIP protokollról szóló videóleckére, tudja, hogy ez a protokoll a frissítések küldésére a 255.255.255.255 széleskörű domént használja, amelyhez az összes alhálózat csatlakozik. De ezeket a frissítéseket csak azok az eszközök kapják meg, amelyek a RIP protokollt használják.
Egy másik típusú adatátvitel, amely nem fordult elő az IPv4-ben, az Anycast. Ezt akkor használják, amikor több eszközöm van ugyanazzal az IP-címmel, és lehetővé teszi a csomagok elküldését a legközelebbi címzettnek a fogadók csoportjából.
Az internet esetében, ahol CDN-hálózatok állnak rendelkezésre, példaként említhetjük a YouTube szolgáltatást. Ezt a szolgáltatást számos ember használja a világ különböző részein, de ez nem jelenti azt, hogy mindannyian közvetlenül a cég kaliforniai szerveréhez csatlakoznak. A YouTube szolgáltatásnak számos szervere van világszerte, például az indiai YouTube szerverem Szingapúrban található. Hasonlóképpen az IPv6 protokoll beépített mechanizmussal rendelkezik a CDN technológián keresztüli adatátvitel lehetővé tételére, földrajzilag elosztott hálózati struktúra segítségével, tehát az Anycast-ot használja.
Ahogy észrevette, itt hiányzik egy másik típusú adatátvitel, a Broadcast, mert az IPv6 protokoll nem használja azt. De a Multicast ebben a protokollban a Broadcast-hoz hasonlóan működik az IPv4-ben, csak hatékonyabb módon.
A protokoll hatodik verziója három címzettípust használ: Link Local, Unique Site Local és Global. Emlékezzünk arra, hogy az IPv4 esetében egy interfésznek csak egy IP-címe van. Tegyük fel, hogy van két router, amelyek kapcsolódnak egymáshoz, így mindkét csatlakozási interfésznek csak egy IP-címe lesz. IPv6 használatakor minden interfész automatikusan kap egy Link Local típusú IP-címet. Ezek a címek FE80::/64-el kezdődnek.
Ez a típusú IP-címek csak helyi kapcsolatokhoz használatosak. A Windows-t használó emberek ismerik a nagyon hasonló címeket, mint például 169.254.X.X – ezek automatikusan konfigurált címek IPv4 protokoll alapján.
Ha egy számítógép DHCP szerverhez fordul IP-cím megszerzéséért, de valamilyen okból nem tud kapcsolatot létesíteni vele, a Microsoft eszközökben van egy mechanizmus, amely lehetővé teszi, hogy a számítógép saját magának hozzon létre IP-címet. Ebben az esetben a cím körülbelül így fog kinézni: 169.254.1.1. Hasonló helyzet merül fel, ha van egy számítógépünk, egy switch és egy router. Tegyük fel, hogy a router nem kapott IP-címet a DHCP-szervertől, és automatikusan egy ugyanolyan IP-címet adott magának, mint a 169.254.1.1. Ezután a switch-en keresztül széles sávú ARP-kérdést küld a hálózaton, amelyben megkérdezi, hogy van-e valamilyen hálózati eszköz, amely ezzel a címmel rendelkezik. A kérdést megkapva a számítógép válaszol: „Igen, nekem is pontosan ilyen IP-címem van!”, ami után a router egy új véletlenszerű címet rendel magához, például 169.254.10.10, és ismét ARP-kérdést küld a hálózaton.
Ha senki sem jelzi, hogy ugyanazzal a címmel rendelkezik, a router megtartja a 169.254.10.10 címet magának. Így a helyi hálózat eszközei egyáltalán nem használhatják a DHCP-szolgáltatót, és saját maguknak automatikusan oszthatják ki az IP-címeket a kapcsolat létrehozásához. Ez az IP-címek automatikus konfigurálásának lényege, amellyel sokszor találkoztunk, de soha nem használtuk.
Hasonlóképpen, az IPv6 protokollban létezik egy Link Local típusú helyi IP-címek kiosztására szolgáló mechanizmus, amely az FE80::-val kezdődik. A /64 jelöli a hálózati címek és a gépcímek elválasztását. Az első 64 a hálózatot, a második 64 pedig a gépet jelenti.
A FE80:: cím olyan címekre utal, mint a FE80.0.0.0/, ahol a perjel után a hoszt címének egy része található. Ezek a címek nem azonosak az eszközünknél és a hozzá csatlakoztatott interfésznél, és automatikusan konfigurálódnak. Ezenkívül a hoszt rész használja a MAC-címet. Mint ismeretes, a MAC-cím egy 48 bites IP-cím, amely 6 blokkra oszlik, mindegyik 2 hexadecimalis számból áll. Ezt a rendszert a Microsoft használja, míg a Cisco 3 blokkot használ 4 hexadecimalis számból.
A példánkban Microsoft által használt 11:22:33:44:55:66 sorrendet fogjuk alkalmazni. Hogyan rendelhetjük hozzá a MAC-címet a készülékhez? Ez a számokból álló sorrend, amely a hoszt címét képviseli, két részre oszlik: a bal oldalán három csoport 11:22:33, a jobb oldalán három csoport 44:55:66, és köztük hozzáadódik az FF és FE. Így jön létre a hoszt IP-címének 64 bites blokkja.
Mint ismert, a 11:22:33:44:55:66 formátumú sorrend a MAC-cím, amely minden egyes eszközhöz egyedileg kapcsolódik. Ha a MAC-cím két csoportja közé beillesztjük az FF:FE-t, akkor egyedülálló IP-címet kapunk az adott eszközhöz. Így jön létre a Local Link típusú IP-cím, amely kizárólag szomszédok közötti kapcsolat létesítésére szolgál, külön konfiguráció és speciális szerverek nélkül. Ez a típusú IP-cím csak egyetlen hálózati szegmensen belül használható, és nem alkalmazható külső kommunikációra ezen a szegmensen kívül.
A következő cím típusa az Unique Site Local Scope, amely megfelel a belső (private) IP-címek IPv4 protokoll 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16 tartományainak. Azért használunk belső private és külső public IP-címeket, mert a NAT technológiáról volt szó az előző órákban. Az Unique Site Local Scope egy olyan technológia, amely belső IP-címeket hoz létre. Mondhatod: 'Imrán, hiszen azt mondtad, hogy minden eszköznek lehet saját IP-címe, ezért váltottunk IPv6-ra', és teljesen igazad van. De egyesek a biztonsági szempontok miatt inkább a belső IP-címek használatát részesítik előnyben. Ilyenkor a NAT tűzfal funkciót lát el, és a külső eszközök nem tudnak véletlenszerűen kapcsolódni a hálózatban található eszközökhöz, mert azok helyi IP-címekkel rendelkeznek, amelyek nem hozzáférhetők az Internet külső hálózatából. A NAT azonban számos problémát okoz a VPN-nel kapcsolatban, például az ESP protokoll esetében. A biztonság érdekében az IPv4 protokoll IPSec-et használt, de az IPv6-ban beépített biztonsági mechanizmus van, így a kapcsolat a belső és külső IP-címek között nagyon egyszerűen létrejön.
Ehhez az IPv6 két különböző cím típust kínál: míg az Unique Local címek az IPv4 belső IP-címeihez kapcsolódnak, addig a Global címek az IPv4 külső címeihez. Sok ember egyáltalán nem szereti használni az Unique Local típusú címeket, mások nem tudják nélkülük megoldani, tehát ez folyamatos viták tárgya. Úgy gondolom, hogy sokkal több előnyhöz juthatsz, ha csak külső IP-címeket használsz, elsősorban a mobilitás szempontjából. Például az én eszközöm mindig ugyanazt az IP-címet fogja viselni, függetlenül attól, hol vagyok – legyen szó Bangalorról vagy New Yorkról –, így bármelyik eszközömet problémamentesen tudom használni a világ bármely pontján.
Ahogy már említettem, az IPv6 beépített biztonsági mechanizmussal rendelkezik, amely lehetővé teszi a biztonságos VPN-alagút létrehozását a hely között, ahol az irodád található, és a te eszközeid között. Korábban szükségünk volt egy külső mechanizmusra egy ilyen VPN-alagút létrehozásához, de az IPv6-ban ez beépített, szabványos mechanizmus.
Mivel ma számos kérdést megvitattunk, megszakítom az óránkat, hogy folytassuk az internetes protokoll, az IP hatodik verziójának megbeszélését a következő videóban. Házi feladatként arra kérem önöket, hogy alaposan tanulmányozzák, mi a hexadecimális számrendszer, mert az IPv6 megértéséhez nagyon fontos, hogy ismerjük a bináris számrendszer hexadecimálisra való átváltását és vissza. Például tudniuk kell, hogy 1111=F, és így tovább, egyszerűen keressenek rá a Google-on. A következő videóórán megpróbálok önökkel gyakorolni az ilyen átváltásokat. Azt javaslom, hogy nézzék meg a mai videóórát többször, hogy ne maradjanak kérdéseik a tárgyalt témákkal kapcsolatban.
Köszönjük, hogy velünk maradnak. Tetszenek Önöknek a cikkeink? Szeretnének több érdekes anyagot látni? Támogassanak minket rendelés leadásával vagy ismerősöknek való ajánlással. 30% kedvezmény a Habr felhasználóinak az egyedülálló entry-level szervereinkre, amelyet Önöknek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd két alkalommal olcsóbban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
