}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Výuková interaktivní animace sít’ového protokolu IPv6 ˇ B AKALÁ RSKÁ PRÁCE
Jiˇrí Kalina
Brno, 2012
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Jiˇrí Kalina
Vedoucí práce: RNDr. Tomáš Rebok, Ph.D. ii
Podˇekování Rád bych podˇekoval vedoucímu mojí bakaláˇrské práce RNDr. Tomáši Rebokovi, Ph.D. za cenné rady, velkou trpˇelivost a jeho cˇ as, které mi vˇenoval pˇri vypracování této bakaláˇrské práce. Dále bych rád podˇekoval své rodinˇe a hlavnˇe svým rodiˇcum ˚ Bc. Jiˇrímu Kalinovi a Hanˇe Kalinové, že mˇe podporovali po celou dobu studia a umožnili mi, abych se mohl plnˇe vˇenovat studiu a tvorbˇe této bakaláˇrské práce. Podˇekování patˇrí také mým spolužákum ˚ Bc. Lukáši Rackovi za udˇelení souhlasu použít jeho animace zabývají se IPsecem a Bc. Janovi Meravému za rady poskytnuté ohlednˇe práce v programu Adobe Flash Professional.
iii
Shrnutí Obsahem mojí bakaláˇrské práce je pˇredstavení funkˇcnosti mechanismu˚ internetového protokolu IPv6 a jejich analýza. Následnˇe jsou pro tyto mechanismy vytvoˇrené výukové animace. V teoretické cˇ ásti popisuji referenˇcní ISO/OSI model a historii vzniku protokolu IPv6. Dále se vˇenuji podrobné analýze základní hlaviˇcky IPv6, rozšiˇrujícím hlaviˇckám, zpusob ˚ um ˚ adresování, protokolu neighbor discovery, autokonfiguraci a mobilitˇe. Na závˇer je ještˇe shrnuto nˇekolik bezpeˇcnostních aspektu˚ v IPv6. Tato cˇ ást slouží pˇredevším jako rozšiˇrující materiál k praktické cˇ ásti práce. V praktické cˇ ásti se nalézají výukové animace vytvoˇrené v programu Adobe Flash Professional CS5. Jejich cílem je pˇredvést fungování mechanismu˚ formou vhodnou k výuce tak, aby je studenti byli schopni pochopit.
iv
Klíˇcová slova IPv6, hlaviˇcky, datagramy, unicast, multicast, anycast, neighbor discovery, dosažitelnost, bezstavová konfigurace, DHCPv6, mobilita, IPsec, bezpeˇcnost, Flash
v
Obsah 1
Úvod . . . . . . . . . . . . . . . . . . . . . . . . 1.1 ISO/OSI . . . . . . . . . . . . . . . . . . . 1.2 Sít’ová vrstva . . . . . . . . . . . . . . . . 2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Historie IPv6 . . . . . . . . . . . . . . . . . 2.2 Datagramy . . . . . . . . . . . . . . . . . . 2.2.1 Základní hlaviˇcka protokolu IPv6 2.2.2 Zˇretˇezení hlaviˇcek . . . . . . . . . 2.2.3 Rozšiˇrující hlaviˇcky . . . . . . . . . 3 Analýza IPv6 komunikace . . . . . . . . . . . 3.1 Adresace . . . . . . . . . . . . . . . . . . . 3.1.1 Zápis adresy . . . . . . . . . . . . . 3.1.2 Unicast . . . . . . . . . . . . . . . . 3.1.3 Multicast . . . . . . . . . . . . . . . 3.1.4 Anycast . . . . . . . . . . . . . . . 3.1.5 Povinné adresy uzlu . . . . . . . . 3.2 Neighbor discovery . . . . . . . . . . . . . 3.2.1 Zjišt’ování linkových adres . . . . 3.2.2 Zjišt’ování dosažitelnosti souseda 3.3 Autokonfigurace . . . . . . . . . . . . . . 3.3.1 Bezstavová konfigurace . . . . . . 3.3.2 DHCPv6 . . . . . . . . . . . . . . . 3.4 Mobilita . . . . . . . . . . . . . . . . . . . 3.4.1 Pˇresun v síti . . . . . . . . . . . . . 3.4.2 Získání domácího agenta . . . . . 3.4.3 Optimalizace cesty . . . . . . . . . 3.4.4 Pˇrenos dat . . . . . . . . . . . . . . 3.4.5 Návrat domu˚ . . . . . . . . . . . . 3.5 Bezpeˇcnost IPv6 . . . . . . . . . . . . . . . 4 Výukové animace protokolu IPv6 . . . . . . . 4.1 Duvody ˚ pro animaci . . . . . . . . . . . . 4.2 Adobe Flash Professional . . . . . . . . . 4.3 Ovládání animací . . . . . . . . . . . . . . 4.4 Vytvoˇrené animace . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . A Obrázky . . . . . . . . . . . . . . . . . . . . . . B Obsah Pˇriloženého CD . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 2 . 3 . 5 . 7 . 7 . 9 . 9 . 10 . 12 . 17 . 17 . 17 . 19 . 22 . 25 . 27 . 28 . 29 . 30 . . 31 . . 31 . 36 . 39 . 39 . 40 . 42 . 44 . 45 . 46 . 48 . 48 . 48 . 49 . 50 . 52 . 56 . 60 1
1 Úvod První poˇcítaˇcová sít’ se objevila v 60. letech 20. století. Tato sít’ propojovala cˇ tyˇri americké univerzity, rychlost mˇela 50 kbit/s a jmenovala se ARPANET (Advanced Research Projects Agency Network). Od poloviny 70. let se zaˇcaly pocˇ ítaˇcové sítˇe využívat také komerˇcnˇe využívat. Do té doby sloužily výhradnˇe k akademickým a experimentálním úˇcelum. ˚ Mnoho výrobcu˚ zaˇcalo vytváˇret vlastní sít’ové produkty. Problém nastal, když se poˇcet uživatelu˚ zvýšil a ti se chtˇeli vzájemnˇe propojit, protože zaˇrízení výrobcu˚ byla proprietární (fungovala na ruzných ˚ technologiích, které vymyslel daný výrobce). Což zpusobilo ˚ jejich vzájemnou nekompatibilitu a bylo nutné pˇrijít s rˇ ešením, kdy by mohli sít’ová zaˇrízení od ruzných ˚ výrobcu˚ mezi sebou komunikovat. Sjednotit technologii výrobcu, ˚ aby byla vzájemnˇe kompatibilní, se povedlo v 80. letech mezinárodní standardizaˇcní organizaci ISO (International Standards Organization, správnˇe: International Organization for Standardization) s referenˇcním modelem OSI. Tímto modelem se více zabývá kapitola 1.1. OSI model nahradila posléze rodina protokolu˚ TCP/IP, které se dosud používají. Souˇcástí TCP/IP je internet protocol. V souˇcasné dobˇe je dominantní Internet Protocol version 4 (IPv4), ale nyní jej zaˇcíná Internet Protocol version 6 (IPv6). První specifikace protokolu IPv6 (RFC 1883) se objevila již v roce 1995, ale byla upravena a od roku 1998 se používá nová specifikace (RFC 2460). Tímto protokolem se zabývá tato bakaláˇrská práce, jejímž cílem je pˇrehlednˇe popsat historii vzniku a fungování protokolu IPv6. Praktickou cˇ ástí práce jsou výukové animace,které prezentují fungování mechanismu˚ IPv6. Textová cˇ ást práce slouží pˇredevším jako rozšiˇrující materiál k daným animacím. IPv6 vznikl hlavnˇe kvuli ˚ docházejícímu adresnímu prostoru v IPv4. Pˇri tvorbˇe IPv6 se však nemyslelo jen na adresní prostor, ale i na další duležité ˚ aspekty, které v základu nebyl IPv4 schopen nabídnout. Hlavními jsou: •
Velký adresní prostor, který by mˇel vydržet pokud možno napoˇrád
•
Tˇri druhy adres unicast (individuální), multicast (skupinové) a anycast (výbˇerové)
•
Jednotné adresní schéma pro Internet a vnitˇrní sítˇe
•
Zvýšení bezpeˇcnosti – zahrnutí schémat pro autentizaci, šifrování a sledování cesty k odesílateli
•
Podpora pro služby se zajištˇenou kvalitou
•
Vysokorychlostní smˇerování 2
1. Ú VOD •
Automatická konfigurace (nejlépe typu plug and play)
•
Podpora mobility
•
Hladký pˇrechod mezi IPv4 a IPv6
1.1
ISO/OSI
Jak již bylo napsáno v úvodu, s komerˇcním rozmachem poˇcítaˇcových sítí v 70. letech byl problém s jejich vzájemnou nekompatibilitou, kterou bylo nutné vyˇrešit. A tohoto úkolu se chopila mezinárodní standardizaˇcní organizace ISO, která pˇrišla s rˇ ešením s názvem Open Systems Architecture. Toto rˇ ešení ovšem nakonec nebylo schváleno a po nˇekolika dalších pokusech byl nakonec v roce 1984 schválen Reference Model for Open Systems Interconnection (Referenˇcní model pro propojování otevˇrených systému) ˚ jako norma ISO 7498. Pro vˇetšinu lidí znám jako referenˇcní model OSI nebo též ISO/OSI model. ISO/OSI model se skládá ze sedmi vrstev, v nˇemž každá vrstva plní urˇcitou úlohu a využívá funkce a služby vrstvy nacházející se bezprostˇrednˇe pod ní. ISO/OSI model zobrazuje obrázek 1.1. Tˇechto sedm vrstev se dále dˇelí do dvou bloku˚ po tˇrech vrstvách, propojených jednou „spojovací“ vrstvou. Blok dolních tˇrech vrstev se stará o pˇrenos dat, zatímco druhý blok se zamˇerˇ uje na podporu aplikací. „Spojovací“ vrstva pak má vyrovnávat rozdíly mezi možnostmi bloku nižších vrstev, a potˇrebami bloku vyšších vrstev [18].
Aplication layer
Aplication layer
Presentation layer
Presentation layer
Session layer
Session layer
Transport layer
Transport layer
Network layer
Network layer
Data link layer
Data link layer
Physical layer
Transmission medium
Physical layer
Obrázek 1.1: ISO/OSI model Vrstvy ISO/OSI modelu Physical layer (Fyzická vrstva) je nejspodnˇejší vrstvou. [6] Úlohou této vrstvy je zajištˇení odeslání jednotlivých bitu˚ mezi pˇríjemcem a odesílatelem 3
1. Ú VOD prostˇrednictvím fyzického média. Pˇredstavuje elektrické, mechanické a optické rozhraní spolu s potˇrebnými softwarovými ovladaˇci komunikaˇcních portu. ˚ Na této úrovni se realizují všechny detaily týkající se pˇrenosového média. Fyzická vrstva je ve skuteˇcnosti pouze reálným spojením mezi dvˇema komunikujícími uzly. Data link layer (Spojová vrstva) je druhá vrstva. Tato vrstva se stará o pˇrenos rámcu. ˚ Zajišt’uje bezchybný pˇrenos dat, protože fyzická vrstva se nezajímá o to, jaká hodnota bitu dorazí. O správnost pˇrenesených dat se musí starat spojová vrstva pomocí kontrolních souˇctu. ˚ V pˇrípadˇe, že data nedorazila v poˇrádku, si vrstva vyžádá zaslání dat znovu. Network layer (Sít’ová vrstva) má na starosti smˇerování v komplexní síti a pˇrenos datových jednotek od zdroje k cíli. Mezi její další úkoly patˇrí dohodnutí kvality služby, sít’ové adresování, zahajování a ukonˇcování sít’ových spojení a oznamování vzniklých chyb. Dále jsou v sít’ové vrstvˇe sdruženy funkce, které umožnují ˇ pˇrekonat rozdíly mezi ruznými ˚ technologiemi v pˇrenosových okruzích a podsítích. Tím je dosaženo konzistence služby. Sít’ová vrstva poskytuje transportní vrstvˇe nezávislost na smˇerování (zajišt’uje spojení mezi jakýmikoliv dvˇema uzly). Pˇri posílání paketu˚ hlídá jejich správné poˇradí a seˇrazuje je podle toho, jak mají být doruˇceny. Na této vrstvˇe pracují protokoly IP (IPv4 a IPv6). Transport layer (Transportní vrstva) je v poˇradí cˇ tvrtá. Transportní vrstva se zabývá komunikací mezi koncovými aplikacemi (tzv. end-to-end komunikaci). Jejím úˇcelem je poskytovat úrovenˇ pˇrenosu jaká je vyžadována vyšší vrstvou. Na této vrstvˇe se nachází transportní protokoly poskytující spolehlivý pˇrenos dat (TCP) a neposkytující spolehlivý pˇrenos dat (UDP). Session layer (Relaˇcní vrstva) je pátá vrstva modelu ISO/OSI. [24] Úkolem vrstvy je organizovat a synchronizovat komunikaci mezi relaˇcními vrstvami obou komunikujících uzlu. ˚ Umožnuje ˇ vytvoˇrení, ukonˇcení, synchronizaci a obnovení relaˇcního spojení a oznamovaní výjimeˇcných stavu. ˚ Presentation layer (Prezentaˇcní vrstva) je šestá vrstva OSI modelu. [20] Má za úkol pˇrevádˇet informace z aplikaˇcní vrstvy do urˇcité jednotné reprezentace, aby bylo posléze možné v aplikaci na druhém uzlu tyto data korektnˇe zobrazit. Mezi ukázkové transformace lze zaˇradit pˇreklad znaku˚ z PC, který používá znaky ASCII (American Standard Code for Information Interchange), na formát EBCDIC (Extended Binary Coded Decimal Interchange Code) využívaných v systémech IBM. Pˇrípadnˇe zobrazování celých cˇ ísel. Zatímco jeden stroj muže ˚ cˇ ísla zobrazovat v doplnkovém ˇ tvaru, jiný je zobrazuje v pˇrímém tvaru a pˇrevod má za úkol prezentaˇcní vrstva. Application layer (Aplikaˇcní vrstva) je poslední vrstva OSI modelu. Úˇcelem vrstvy je poskytovat aplikaˇcním procesum ˚ pˇrístup ke komunikaˇcnímu 4
1. Ú VOD systému a tím umožnit jejich vzájemnou spolupráci. Na této vrstvˇe operují kromˇe aplikací i aplikaˇcní protokoly. Tˇemi hlavními jsou WWW aplikace a jí pˇriˇrazený protokol HTTP, email s protokolem SMTP a pˇrenos souboru˚ s protokolem FTP. Koncepce celého ISO/OSI modelu se nikdy prakticky nepoužívala, ale v praxi se používá velké množství jejích myšlenek a principu. ˚ Nejznámˇejší protokol, který z ISO/OSI prakticky vychází, je TCP/IP. Ten používá cˇ tyˇri vrstvy, ISO/OSI sedm. Nejˇcastˇeji se lze s modelem ISO/OSI setkat jako s výukovým materiálem pro svou pˇrehlednost a jednoduchost. Aplication layer Presentation layer
Aplication layer
Session layer Transport layer
Transport layer
Network layer
Internet layer
Data link layer Physical layer
Network acces layer
ISO/OSI
TCP/IP
Obrázek 1.2: Protokol TCP/IP
1.2
Sít’ová vrstva
Jelikož se bakaláˇrská práce zabývá protokolem IPv6, který se nachází na sít’ové vrstvˇe, je vhodné podrobnˇeji popsat její fungování. Sít’ová vrstva je tˇretí vrstva ISO/OSI modelu. Pod vrstvou se nachází spojová vrstva a nad ní transportní vrstva. Sít’ová vrstva má hlavnˇe na starosti smˇerování v síti. [19] Pokud jsou pˇrenášena nˇejaká data, tak o pˇrenos mezi uzly se stará spojová vrstva, ovšem kterému uzlu se mají data odeslat, urˇcuje právˇe sít’ová vrstva. Pokud jsou mezi dvˇema komunikující mu uzly jiné prvky, pˇres které musí data projít, tak sít’ová vrstva urˇcí cestu, kudy data bude smˇerˇ ovat. Když data dorazí k uzlu, spojová vrstva pˇredá tato data sít’ové vrstvˇe, která urˇcí, jestli data došla k cílovému pˇríjemci. Pokud je uzel pouze pruchozí, ˚ pˇredá data zpˇet spojové vrstvˇe a oznámí jí, kam dále má data poslat. Až se takto data nakonec dostanou k cílovému uzlu. U nˇej potom sít’ová vrstva zjistí, že data dorazila kam mˇela, a pˇredá je transportní vrstvˇe, kde jsou data dále zpracována. 5
1. Ú VOD Protože pro transportní vrstvu jsou uzly vždy vedle sebe, poskytne sít’ové vrstvˇe jen adresu koncového uzlu. Sít’ová vrstva odhaduje, kterým smˇerem má data poslat. Na základˇe této adresy a s pomocí smˇerovacích tabulek nachází nejlepší možnou cestu k cíli. Další vˇecí, kterou by mˇela sít’ová vrstva provádˇet, je pˇredcházet pˇri smˇerování zahlcení sítˇe a snažit se zajistit rovnomˇerné rozdˇelení zátˇeže.
6
2 IPv6 IPv6 je tu s námi už pomˇernˇe dlouho, i když podle poˇctu lidí co používají IPv6, se muže ˚ zdát, že IPv6 funguje maximálnˇe 2 roky. Pˇritom specifikace protokolu IPv6 byla hotova již v roce 1998. I pˇres svuj ˚ pomalý rozjezd, muže ˚ IPv6 nabídnout vˇeci které IPv4 nemuže. ˚ Za všechny uvedu pár pˇríkladu: ˚ bezstavová konfigurace, IPsec a podpora mobility. Hodí se pˇripomenout, co pˇredcházelo protokolu, kdysi oznaˇcovanému jako IP next generation.
2.1
Historie IPv6
V úvodu jsem popsal krátce historii IPv6. V této cˇ ásti se jí budu vˇenovat podrobnˇeji. První poˇcítaˇcová sít’ byla vytvoˇrena v 60. letech 20. století. Touto sítí byla ARPANET, jejíž vznik byl financován ministerstvem obrany USA a mˇela za úkol zjistit fungování sítˇe pomocí pˇrepínaných paketu˚ a bez centrálního místa. Taková sít’ je schopna fungovat i v pˇrípadˇe, že nˇekteré cˇ ásti jsou odpojeny (zniˇceny). Zárovenˇ umožnovala ˇ vzdálený pˇrístup k nejvýkonnˇejším poˇcítaˇcum ˚ tehdejší doby. Základem ARPANETu se staly poˇcítaˇce na 4 univerzitách v USA1 . Vubec ˚ první paket byl poslán v této síti 29. rˇ íjna 1969 z poˇcítaˇce umístˇeného v univerzitˇe v Los Angeles do Stanfordu a jednalo se o pokus o pˇrihlášení. Protokolem, který se používal pro vzájemnou komunikaci, byl NCP (Network Control Program). NCP používal 8 bitovou adresaci s možností pˇripojit až 256 uzlu˚ a pˇrinesl nˇekteré služby, které se používají dosud. Napˇr. e-mail a FTP (File Transfer Protocol). Poˇcet pˇripojených poˇcítaˇcu˚ se postupnˇe zvyšoval a v záˇrí 1973 bylo pˇripojeno 40 poˇcítaˇcu. ˚ V témže roce se navíc pˇripojily poˇcítaˇce umístˇené mimo území USA a to v Oslu a v Londýnˇe. V roce 1981 bylo pˇripojeno celosvˇetovˇe již 213 poˇcítaˇcu˚ a nové se stále pˇripojovaly. V roce 1983 se ARPANET rozdˇelil na vojenskou a veˇrejnou cˇ ást. Ještˇe pˇred tímto rozdˇelením byl 1. ledna 19832 NCP protokol nahrazen protokolem TCP/IP. Každý pˇripojený uzel byl odpojen a znovu pˇripojen už s novým protokolem. TCP/IP protokol nabízel oproti NCP 32 bitovou adresaci (IPv4), což znamenalo adresní prostor o velikosti 4 294 967 296 pˇripojených uzlu. ˚ Po urˇcité dobˇe, kdy ARPANET sloužil pouze jako páteˇrní sít pro ostatní pˇripojené sítˇe, byl v bˇreznu 1990 vypnut. 1. University of California Los Angeles, Stanford Research Institute, University of California Santa Barbara a University of Utah 2. Tomuto dni se také jinak rˇ íká Flag Day.
7
2. IP V 6 Protokol IPv4 nahradil NCP v ARPANETu. IPv4 je popsán v RFC 791, které vzniklo v roce 1981, 2 roky pˇredtím než byl nasazen do provozu. Du˚ vod, proˇc nový protokol má verzi 4, je ten, že verze 0–3 byly pouze vývojové, a nikdy se s nimi nepoˇcítalo s nasazením do ostrého provozu. TCP/IP pˇrinesl kromˇe vˇetšího adresního prostoru i služby ICMP, ARP, DNS, HTTP a další. Zárovenˇ zachoval e-mail a FTP. Dnešní Internet funguje na protokolech a službách TCP/IP. Bohužel stejnˇe jako u NCP i v IPv4 postupnˇe docházelo místo pro nové stroje, což bylo zpusobeno ˚ špatným hospodaˇrením s IP adresami. Aby se zabránilo vyˇcerpání adres, pˇrišlo se s mechanismem pro pˇridˇelování IP adres CIDR (Classless Inter-Domain Routing). Když bylo jasné, že místo stejnˇe dojde (3. února 2011 skuteˇcnˇe došlo. Byl rozdán poslední blok IPv4 adres.), tak se rozhodlo o pˇrechodu k nové verzi IP protokolu, který by mˇel vˇetší adresní prostor a zárovenˇ opravoval nedostatky, na které se pˇrišlo v prubˇ ˚ ehu fungování IPv4. Nová verze IP zaˇcala vznikat už na poˇcátku 90. let tehdy ještˇe pod názvem IPng (Internet Protocol next generation). Její základní cíle, kromˇe velikosti adresního prostoru, byly tˇreba bezpeˇcnost, jednoduchost, robustnost, snadná správa, jednoduchá rozšiˇritelnost, tunelování a mnoho dalších. Všechny požadavky jsou shrnuty v RFC 1752. V prosinci 1995 vznikl standart RFC 1883 Internet Protocol, Version 6 (IPv6) specification. Kde se už nemluví o IPng, ale pˇrímo o IPv6. Verze IPv5 je pˇreskoˇcena, protože šlo o experimentální protokol pro pˇrenos hlasu a videa po síti (Internet Stream Protocol). RFC 1883 mˇela již vyˇrešen adresní prostor, zjednodušení hlaviˇcek i jejich následné zˇretˇezení a bezpeˇcnost. Nakonec vyšla ještˇe jedna finální specifikace a to RFC 2460 v prosinci 1998, která nˇekteré vˇeci upravuje cˇ i doplnuje. ˇ Tato je platná dosud. Nasazení IPv6 do provozu není až tak rychlé, jaké byly puvodní ˚ plány. V lednu 2012 byl poˇcet poˇcítaˇcu˚ pˇripojujících se ke službám pomocí IPv6 pouze nˇejakých 0,6%. [13] Duvod ˚ u, ˚ proˇc je to tak málo, je hned nˇekolik. Za prvé zpˇetná nekompatibilita s IPv4. Uživatelé, kteˇrí mají pouze IPv6 by se nedostali ke službám, které bˇeží pouze na IPv4. Kvuli ˚ tomuto vzniklo nˇekolik mechanismu, ˚ které umožnují ˇ pˇrechod ze starého protokolu na nový. V praxi se ale moc nepoužívají. Další problém je zaˇcarovaný kruh. Uživatelé nemají duvod ˚ pˇrecházet na nový protokol, když na nˇem nejsou žádné služby a poskytovatelé služeb nepˇrechází z duvodu, ˚ že na novém protokolu nejsou žádní uživatelé. Významní poskytovatelé služeb a politici se snaží popostrˇcit k vˇetšímu provozu pomocí IPv6, což dokládá tˇreba i „IPv6 Day“ v cˇ ervnu 2011. Další duvod ˚ malého rozšíˇrení je pomalý vývoj specifikací zejména DHCPv6. Jeho pˇredešlá verze (DHCP) se hojnˇe používá, proto je velmi pˇrekvapující, že se specifikace tvoˇrila dlouhých 8 let. 8
2. IP V 6
2.2
Datagramy
Datagramy jsou základní prvky, které jsou pˇrenášeny v rámci IPv6 sítˇe. Jedná se o ucelený blok dat s pevnˇe danou strukturou. Skládá se ze základní hlaviˇcky, za níž mohou být rozšiˇrující hlaviˇcky. Za nimi následují následují pˇrenášená data. Tˇemi mohou být datové bloky TCP, UDP nebo data která jsou nutná pro správné fungování uzlu v síti (ICMP). Tohle všechno tvoˇrí datagram. Pˇrestože to nemusí být dále uvedeno, všechny zprávy se zasílají v podobˇe datagramu. 2.2.1 Základní hlaviˇcka protokolu IPv6 Základní hlaviˇcka (Basic header) protokolu IPv6 se od své pˇredchudkynˇ ˚ e liší v nˇekolika vˇecech. Pˇredevším vˇetší pˇrehledností, protože hlaviˇcka v IPv6 neobsahuje žádné volby, ty mají svou vlastní hlaviˇcku. Další vˇecí, která se zmˇenila, je délka hlaviˇcky, která má délku 40 bytu˚ (je dvakrát delší než dˇrív). Formát základní hlaviˇcky, je vidˇet na obrázku 2.1. 0 bits
Version
8 bits
16 bits
24 bits
32 bits
Flow label
Traffic class Payload length
Hop limit
Next header
Source address
Destination address
Obrázek 2.1: Základní hlaviˇcka protokolu IPv6 Základní hlaviˇcka se skládá z polí urˇcité délky. Jsou to: Version (verze) specifikuje použitou verzi IP protokolu. Toto pole má délku 4 bity a jak je jistˇe zˇrejmé, její hodnotou je cˇ íslo 6. Traffic class (tˇrída provozu)je osmibitové pole a vyjadˇruje prioritu datagramu. Priorita urˇcuje kvalitu služby, jako je rychlost nebo zpoždˇení. Sít’ové prvky využívají jeho hodnotu pro urˇcení zpusobu ˚ zacházení s datagramem (pˇrednostní zpracování, cˇ i odsunutí datagramu až za ostatní). V souˇcasnosti stále není možné toto zajistit, proto je hodnota tohoto pole implicitnˇe nastavena na 0. Flow label (znaˇcka toku) slouží k identifikaci proudu datagramu, ˚ které se vyznaˇcují stejnými vlastnostmi jako jsou odesílatel nebo pˇríjemce. Znaˇcka 9
2. IP V 6 toku slouží jako identifikátor pro router, aby poznal, že urˇcité datagramy patˇrí k sobˇe a zacházel se všemi stejnˇe. Pokud datagram nepatˇrí k žádnému proudu, je hodnota nastavena na 0. Pokud uživatel nastavuje znaˇcku toku tak je požadováno, aby hodnotu pˇridˇeloval náhodnˇe a pamatoval všechny své pˇredchozí toky. Payload length (délka dat) nese údaj o délce datagramu. Do délky se nezapoˇcítává základní hlaviˇcka, ale až další hlaviˇcky a data která následují. Tato položka je šestnáctibitová což znaˇcí, že maximální délka datagramu muže ˚ být 64 KB. V pˇrípadˇe, že je potˇreba delší datagram, použije se ve volbách rozšiˇrujících hlaviˇcek jumbo obsah, což umožní poslat datagram delší než 64 KB. Tato volba se pˇríliš nepoužívá, at’ už z duvodu ˚ velikosti MTU (Maximum Transmission Unit), které není vˇetšinou tak velké, ale zejména proto, že jumbo obsah vadí protokolum ˚ vyšších vrstev (UDP). Next header (další hlaviˇcka) se využívá k identifikaci následující rozširˇ ující hlaviˇcky. Toto pole se nachází v každé rozšiˇrující hlaviˇcce. Kromˇe urˇcení následující hlaviˇcky se využívá také k identifikaci typu dat, která jsou v datagramu zasílána. Více se touto položkou zabývám v kapitole 2.2.2. Hop limit (dosah) nahradil dˇrívˇejší životnost (TTL – time to Live). Hodnota pole urˇcuje, kolik možných skoku˚ muže ˚ datagram absolvovat, než je zahozen. Každý pruchod ˚ routerem je považován za jeden skok a router vždy sníží tuto hodnotu o jedna. Pokud dojde až ke snížení na hodnotu nula, router datagram zahodí a informuje o tom odesílatele pomocí ICMP zprávy. Cílem tohoto omezení je zamezení vzniku cyklu˚ pˇri smˇerování (takový datagram nebude bloudit v síti do nekoneˇcna). Poslední dvˇe pole, z nichž každé má velikost 128 bitu, ˚ jsou source address a destination address (zdrojová a cílová adresa) a slouží k identifikaci odesílatele a pˇríjemce datagramu nebo prvního uzlu pokud je pˇrítomna rozšiˇrující hlaviˇcka Routing (smˇerování). 2.2.2 Zˇretˇezení hlaviˇcek Základní hlaviˇcka obsahuje jen to nejnutnˇejší, aby mohl datagram dorazit ke svému cíli. Pokud je nutné, aby datagram prošel urˇcitými uzly a každý uzel nˇeco vykonal nebo je potˇreba daný datagram zašifrovat, tak na to základní hlaviˇcka nestaˇcí. Proto se rozhodlo, že rozšiˇrující volby budou mít vlastní hlaviˇcku, která se bude v pˇrípadˇe potˇreby pˇridávat za základní hlaviˇcku. Aby mohly uzly v síti poznat, že datagram má rozšiˇrující hlaviˇcky, obsahuje každá hlaviˇcka pole next header (u rozšiˇrujících hlaviˇcek je typicky první, až na ESP). Podle hodnoty v tomto poli se urˇcuje, která rozšiˇrující hlaviˇcka následuje 10
2. IP V 6 za souˇcasnou. Poslední hlaviˇcka v tomto rˇ etˇezci má v next header typ nesených dat. Pokud datagram neobsahuje žádné rozšiˇrující hlaviˇcky, bude mít pˇrímo základní hlaviˇcka v poli next header typ nesených dat. Nejpoužívanˇejší hodnoty jsou zobrazeny na obr. A.1. Kompletní seznam všech hodnot se nalézá na stránkách organizace IANA3 . Pˇríklad zˇretˇezení je vidˇet na obrázku 2.2. IPv6 Basic header TCP
Next header: 6 a) Bez rozšiřujících hlaviček
IPv6 Basic header
Hop by Hop options
Next header: 0
Next header: 6
TCP
b) S rozšiřující hlavičkou Hop by Hop options
IPv6 Basic header
Hop by Hop options
Routing header
Next header: 0
Next header: 43
Next header: 6
TCP
c) S hlavičkama Hop by Hop options a Routing
Obrázek 2.2: Pˇríklad zˇretˇezení hlaviˇcek V pˇrípadˇe použití rozšiˇrujících hlaviˇcek by mohl být pruchod ˚ datagramu sítí nezanedbatelnˇe zpomalen, pokud by se každý router na cestˇe musel zabývat zpracováním všech hlaviˇcek. Proto bylo zavedeno urˇcité poˇradí zˇretˇezení. Toto poˇradí je následující: 1.
Basic header (Základní hlaviˇcka IPv6)
2.
Hop by Hop options (Volby pro všechny)
3.
Destination options (Volby pro cíl – pro první cílovou adresu datagramu a pˇrípadné další uvedené v routing header)
4.
Routing header (Smˇerování)
5.
Fragment header (Fragmentace)
6.
Authentication header (Autentizace)
7.
Encapsulating Security Payload header (Šifrování obsahu)
3. http://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xml
11
2. IP V 6 8.
Destination options (Volby pro cíl – pro koneˇcného pˇríjemce datagramu)
9.
Mobility header (Mobilita)
Toto uspoˇrádání by mˇelo zajistit, aby se router zbyteˇcnˇe nezabýval zpracováním hlaviˇcek, pokud pro nˇej nemají žádný význam. [12] Pro pruchozí ˚ router má smysl zabývat se datagramem pouze, pokud za základní hlaviˇckou následuje hlaviˇcka Hop by hop. Ta se pozná podle next header, které má hodnotu 0. Pokud je hodnota jiná, tak se router datagramem hloubˇeji nezabývá, pouze ho pošle dál. Ostatní hlaviˇcky jsou duležité ˚ pouze pro koncového nebo prubˇ ˚ ežného adresáta (který je uveden v hlaviˇcce Routing). Prubˇ ˚ ežný adresát se zajímá pouze o hlaviˇcky Hop by hop, Destination options a Routing. Koncový adresát se musí zabývat všemi hlaviˇckami. Každá rozšiˇrující hlaviˇcka se muže ˚ v datagramu vyskytnout maximálnˇe jednou, výjimkou je pouze hlaviˇcka Destination options, která se muže ˚ vyskytnout pˇred smˇerováním i mobilitou. Samotnými hlaviˇckami se budu zabývat v následující kapitole. Speciální význam má, pokud položka next header obsahuje hodnotu 59 (no next header). Ta signalizuje, že se jedná o poslední hlaviˇcku, za kterou již nenásleduje vubec ˚ nic. Pokud datagram podle své délky obsahuje ještˇe nˇejaká data, musí být ignorována. Je-li datagram pˇreposílán dále, musí do nˇej pˇredávající tato data zkopírovat beze zmˇeny. 2.2.3 Rozšiˇrující hlaviˇcky Hlaviˇcky obsahující volby Hlaviˇcka obsahující volby je zvláštní v tom že se jako jediná muže ˚ objevit v zˇretˇezení vícekrát, jednou jako Hop by hop (volby pro všechny) a dále jako Destination options (volby pro cíl). Formát této hlaviˇcky ukazuje obr. 2.3. Tato hlaviˇcka má promˇenlivou délku v závislosti na velikosti pole options, které nese. Pole options pˇredstavuje nejduležitˇ ˚ ejší cˇ ást a každou volbu v tomto poli používá trochu jinak. Pˇresto mají volby jednotný formát, který je vidˇet na obrázku 2.4. Ten je pˇredepsán tak, že první byte identifikuje, o jakou volbu se jedná (option type, typ volby), druhý byte oznamuje délku volby bez prvních dvou bytu˚ (option data length, délka dat). Na závˇer jsou obsaženy samotné volby (option data, data volby). V option type jsou pˇredepsány významy prvních tˇrí bitu. ˚ Hlaviˇcka Hop by hop obsahuje následující volby Pad1, PadN, Router alert (upozornˇení smˇerovaˇce), Quickstart (rychlý start) a Jumbo payload (jumbo obsah). Pad1 a PadN slouží pouze ke vkládání volného místa tzv. „vaty“, 12
2. IP V 6 8 bits
0 bits
16 bits
24 bits
32 bits
Header length
Next header
Options
Obrázek 2.3: Formát hlaviˇcky obsahující volby Mění se po cestě: 0 - nemění se 1 - může se změnit
Option type
Option data
Option data length 8 bits
16 bits
Co se má udělat, pokud uzel nezná tuto volbu: 00 01 10 11
-
přeskočit a pokračovat dalšími volbami zahození datagramu zahození datagramu a odeslání ICMP odesílateli zahozeni datagramu a odeslání ICMP odesílateli, pokud cílová adresa nebyla skupinová
Obrázek 2.4: Formát pole options sloužící k lepšímu zarovnání ostatních prvku. ˚ Hop by hop hlaviˇcka se muže ˚ vyskytovat pouze pˇrímo za základní hlaviˇckou. Pad1 vynechává jeden byte a má triviální tvar, protože obsahuje pouze hodnotu 0, cˇ ímž identifikuje typ volby a oznamuje, že to je vše. PadN vynechává dva a více bytu. S tím že první byte má hodnotu 1, druhý bajt oznamuje délku volby bez prvních dvou bytu. ˚ Zbylé byty obsahují hodnotu 0. Router alert slouží k tomu, aby routerum ˚ po cestˇe oznámila, že datagram nese pro nˇe potenciálnˇe zajímavá data. Pokud jsou data zajímavá pro router, tak se jimi podrobnˇeji zabývá, jinak datagram pˇrepošle dál. Volba Router alert se pozná podle hodnoty 5. Quickstart slouží ke zvýšení propustnosti transportních protokolu, ˚ zejména TCP. Odesílatel datagramu v této volbˇe navrhuje rychlost, jakou by rád používal. Každý router, kterým datagram projde, muže ˚ tuto hodnotu snížit na pro nˇej pˇrijatelnou mez. V koncovém uzlu obsahuje tedy hodnotu pˇrijatelnou pro každý router na cestˇe. Tato hodnota se cˇ as od cˇ asu aktualizuje. Zatím je tato funkce pouze experimentální. Tuto volbu identifikuje hodnota 6. Poslední volbou je Jumbo payload. Používá se, pokud by nestaˇcila základní maximální velikost pro datagram. Limit pro datagram je nastaven na 65 535 bytu, ˚ jelikož je hodnota velikosti umístˇena v dvoubytovém poli. Což by v základu mˇelo pˇredstavovat dostateˇcnou velikost pro všechna bˇežná použití. V pˇrípadˇe že by nˇekomu tato velikost nedostaˇcovala, jumbo obsah umožnuje ˇ vytváˇret datagramy o maximální velikosti 4 294 967 295 bytu˚ 13
2. IP V 6 (délka je umístˇena v cˇ tyˇrbytovém poli). Pˇri použití jumbo obsahu se délka dat v základní hlaviˇcce nastaví na 0. Datagramum ˚ obsahujícím jumbo obsah se rˇ íká jumbogramy. Aby bylo možné použít jumbogramy musí být MTU vˇetší než onˇech 65 535 bytu. ˚ Jumbo obsah vadí nˇekterým protokolum ˚ vyšší vrstvy. Napˇríklad TCP i UDP mají maximální velikost pro datagram nastaven shodnˇe na 65 535 bytu. ˚ Stroje, které mají zpracovat jumbogramy, musí mít tuto velikost nastavenou na vyšší hodnotu. Hlaviˇcka Destination options obsahuje stejnˇe jako Hop by hop hlaviˇcka, volby Pad1 a PadN pro vkládání vaty, dále obsahuje volbu Home address (Domácí adresa). Domácí adresa se používá pˇri mobilitˇe. Mobilní uzel totiž jako zdrojovou adresu používá svou doˇcasnou a v této volbˇe informuje adresáta o své domovské adrese. Tato volba má v prvním bytu hodnotu 201. Routing header Hlaviˇcka Routing umožnuje ˇ pˇredepsat, aby datagram na své cestˇe prošel ruznými ˚ uzly (routery) v urˇcitém poˇradí. Zárovenˇ umožnuje ˇ uchovávat si záznam, pruchodu. ˚ Pˇri procházení není nutné, aby pˇredepsané uzly následovaly bezprostˇrednˇe za sebou, ale muže být mezi nimi libovolný poˇcet jiných routeru. ˚ IPv6 zavedlo dva typy routing headers, typ 0 a typ 2. První typ je routing header typu 0. Formát hlaviˇcky je zobrazen na obrázku 2.5. Že se jedná o smˇerování typu 0 je poznat podle pole routing type, ve kterém je hodnota 0. Pole segments left oznamuje, kolika z pˇredepsaných uzlu˚ již datagram prošel. Pole addresses obsahuje IP adresy uzlu˚ kterými má datagram projít. Pˇri použití typu 0 se jako destination address v základní hlaviˇcce nastaví IP adresa prvního uzlu, kterým musí datagram projít. Když dorazí do uzlu uvedeného v destination address, zjistí, jestli je pole segments left nulové. Pokud je tam jiná hodnota než 0, vezme první adresu z routing header a nastaví jí jako destination address v základní hlaviˇcce. Zárovenˇ s tím zmenší hodnotu segments left o 1 a datagram odešle dále. Z toho vyplývá, že cílový uzel, kam má datagram doputovat je ten poslední v routing header. V pˇrípadˇe, že je pˇri pˇrijmutí datagramu hodnota segments left 0, znamená to, že datagram dorazil do svého cíle. Routing header typu 2 je pouze zjednodušením typu 0. Typ 2 obsahuje pouze jednu adresu. Formát hlaviˇcky je vidˇet na obrázku 3.18. Tento typ nachází uplatnˇení pouze v mobilitˇe, pro kterou byl pˇrímo definován. Jediná uvedená adresa je domácí adresa mobilního uzlu. Mobilní uzel má totiž dvˇe adresy, domácí a doˇcasnou, na které se zrovna nachází. Podrobnˇeji se budu touto hlaviˇckou zabývat v kapitole 3.4. Na konec je vhodné zmínit, že hlaviˇcka typu 0 byla zakázána [2]. Hlav14
2. IP V 6 8 bits
0 bits
Next header
16 bits
Header length
24 bits
Routing type
32 bits
Segments left
Reserved
Address [1]
Address [n]
Obrázek 2.5: Routing header (Hlaviˇcka smˇerování) ním duvodem ˚ pro zakázání typu 0 bylo možné zahlcení sítˇe pˇri použití smˇerovacích hlaviˇcek naplnˇených maximálním možným poˇctem adres pru˚ ˇ chozích uzlu. ˚ Címž bylo možné zpusobit, ˚ že se datagram pˇreposílal v síti velmi dlouho. Vˇetšinou se samozˇrejmˇe neposílá jen jeden datagram, ale mnohem více. Bylo pˇredvedeno vytvoˇrení datového objemu, který byl 88x vˇetší než byla konektivita pˇripojení [7]. Další duvod, ˚ který pomohl k odmítnutí routing header typu 0 bylo, že je možné pomocí ní procházet NATem na neveˇrejnou adresu. Za podmínky nastavení neveˇrejné adresy jako poslední adresy v routing header a adresa implicitního routeru sítˇe, kde se neveˇrejný uzel nachází, bude uvedena jako pˇredposlední adresa v hlaviˇcce Routing. Fragment header Fragmentace slouží k rozdˇelení datagramu, pokud je jeho velikost vˇetší než MTU linky, po které data procházejí. [8] Fragmentace v IPv6 se liší od té v IPv4. V IPv4 mohl fragmentovat každý router, kterým data procházela, pokud byla MTU linky vˇetší než velikost datagramu. V IPv6 muže ˚ fragmentovat pouze odesílající uzel. Pokud je MTU na lince menší než velikost datagramu, musí jej router na lince zahodit a poslat odesílateli ICMP zprávu, že paket je moc velký. Jako souˇcást tohoto hlášení je i velikost MTU, které se má nastavit. Fragmetace byla v IPv4 souˇcástí základní hlaviˇcky, zatímco v IPv6 má pˇridˇelenou vlastní hlaviˇcku, která je vidˇet na obrázku 2.6. Nejvýznamnˇejší pole v hlaviˇcce jsou fragment offset (posun fragmentu), M-flag (more fragments, více fragmentu) ˚ a identification (identifikace). Pole identification slouží k identifikaci paketu, ˚ které patˇrí k sobˇe. V tomto poli se nalézá celé cˇ íslo, které by mˇelo být u každého dalšího fragmentovaného 15
2. IP V 6 8 bits
0 bits
Next header
16 bits
Reserved
24 bits
Fragment offset
32 bits
Res
M
Identification
Obrázek 2.6: Fragment header datagramu odesílaného z jednoho uzlu v rámci komunikující dvojice o jedna vˇetší. V pˇrípadˇe dosažení maximálního možného cˇ ísla, které se do daného pole vejde (4 294 967 296), se pokraˇcuje od jedniˇcky. Fragment offset oznamuje, kam patˇrí data v paketu v rámci fragmentovaného datagramu. M-flag oznamuje pouze, zda je daný fragment poslední v tom pˇrípadˇe má hodnotu 0 nebo následuje další potom má hodnotu 1. Pokud musí dojít k fragmentaci, rozdˇelí se puvodní ˚ datagram na dvˇe cˇ ásti fragmentovatelnou a nefregmentovatelnou. Nefragmentovatelná cˇ ást datagramu je základní hlaviˇcka a každá další hlaviˇcka až po routing header. Jakákoliv cˇ ást za routing header poˇcínaje fragment header je považována za fragmentovatelnou. Tato fragmentovatelná cˇ ást je rozdˇelena na úseky, jejichž velikost je dˇelitelná 8. A zárovenˇ dost malá aby spolu s hlaviˇckami, které se k nim pˇridají, mˇela menší velikost než MTU, kvuli ˚ kterému se musí fragmentovat. K tˇemto cˇ ástem se ještˇe musí pˇridat hlaviˇcky, aby bylo možné je odeslat. Z puvodního ˚ datagramu se pˇrevezme nefragmetovatelná cˇ ást a udˇelají se v ní zmˇeny ve velikosti dat v poli (payload length). V poslední hlaviˇcce se zmˇení hodnota v next header na 44 a vloží se za ní fragment header. Na závˇer se vloží data. Takto vytvoˇrené fragmenty jsou odeslány pˇríjemci, který si poskládá z pˇríchozích fragmentu˚ puvodní ˚ datagram. I když IPv6 umí normálnˇe pracovat s fragmenty, snaží se, aby ke fragmentaci pokud možno nedocházelo. Jedním z nástroju˚ jak omezit fragmentaci je požadavek na minimální velikost MTU v IPv6. IPv6 protokol obsahuje více hlaviˇcek než je v této kapitole zmínˇeno. Tˇemi se budu zabývat v cˇ ástech které tyto hlaviˇcky využívají. ESP header a Authentication header jsou v kapitole 3.5. Mobility header se nalézá v kapitole 3.4.
16
3 Analýza IPv6 komunikace Tato cˇ ást slouží jako doplnkový ˇ materiál pro dukladný ˚ popis mechanismu, ˚ pro které byly vytvoˇreny výukové animace. Vˇetšina mechanismu˚ které jsou zde popisovány v sobˇe nenesou klasická data typu TCP a UDP. Tyto mechanismy používají zpravidla ICMP zprávy, které slouží k výmˇenˇe informací nutných pro provoz IPv6. I když to nemusí být zmínˇeno, všechny zprávy jsou pˇrenášeny prostˇrednictvím datagramu.
3.1
Adresace
Adresy v IPv6 prošly celkem razantní promˇenou. Zmˇenila se jejich forma, zvˇetšil se adresní prostor, pˇribyl jeden adresní typ a jeden zmizel. Adresy v IPv6 se pˇridˇelují rozhraním, stejnˇe jako tomu je v IPv4. Za rozhraní se dá považovat sít’ová karta, nikoliv poˇcítaˇc. Novinkou v IPv6 je, že každé rozhraní musí mít více adres. A na každé adrese musí pˇrijímat pˇríchozí komunikaci. V IPv6 existují tˇri základní typy adres s ruzným ˚ chováním. Tyto jsou unicast, multicat a anycast. Unicast je základní typ, se kterými se lze setkat nejˇcastˇeji. Komunikace probíhá mezi dvˇemi konkrétními uzly. Multicast je urˇcen k adresování skupiny uzlu, ˚ kde data odeslaná na multicastovou adresu, musí být doruˇcena každému uzlu, který je cˇ lenem dané skupiny. Multicast nahrazuje navíc broadcastové adresy, které se v IPv6 již neobjevují. Anycast je novinkou v IPv6. Navenek se anycastová adresa tváˇrí jako unicastová, ale za touto adresou se skrývá skupina zaˇrízení. Data poslaná na tuto adresu jsou doruˇcena pouze jednomu uzlu ve skupinˇe. 3.1.1 Zápis adresy IPv4 adresa je 32-bitová a vypadá takto 192.168.1.1. Adresa se píše v desítkové soustavˇe do 4 bloku˚ oddˇelených teˇckami, pˇriˇcemž v každém bloku je možné mít cˇ ísla od 0 do 255. Což dává dohromady pˇres 4 mld. ruzných ˚ kombinací. Adresa v IPv6 je 128-bitová neboli 4 násobnˇe delší. Používá šestnáctkovou soustavu a obsahuje 8 bloku, ˚ v každém bloku 4 znaky. Ty jsou oddˇeleny dvojteˇckou. Ve výsledku to dává 3, 4 ∗ 1038 ruzných ˚ adres. Pˇríkladem IPv6 adresy muže ˚ být: 2001:71d8:8e01:1230:54a9:ff7b:0fe1:0001. Od zaˇcátku se oˇcekávalo, že se bude striktnˇe používat DNS, takže uživatelé 17
3. A NALÝZA IP V 6 KOMUNIKACE nebudou muset zadávat do adresního rˇádku tuto „hruzu“. ˚ Bohužel ušetˇreni nejsou správci sítˇe, kteˇrí budou muset tento tvar používat. Zkracování adresy IPv6 adresu je možné zkrátit, ovšem pouze podle existujících pravidel. V adrese se pomˇernˇe cˇ asto vyskytuje cˇ íslo 0, tak se všechny pravidla týkají právˇe tohoto cˇ ísla. První pravidlo je, že je možné vynechat poˇcáteˇcní nuly v každém bloku a blok samých nul lze zapsat jako jednu nulu. Pro pˇríklad tuto adresu 0123:5310:0000:0000:0000:00fe:ab48:3310 je možné zapsat jako 123:5310:0:0:0:fe:ab48:3310. Dále je možné nahradit nulové bloky zápisem „::“. V tom pˇrípadˇe pujde ˚ stejná adresa zkrátit až na 123:5310::fe:ab48:3310. Nulu na konci bloku ani uprostˇred nelze vynechat Pokud by se vynechala nula v bloku :5310:, vzniklo by :531:, ale to neznamená :5310:, nýbrž :0531:. V pˇrípadˇe, že by se celá adresa skládala ze samých nul, šlo by tuto adresu zapsat jako „::“. Zápis „::“lze použít v každé adrese pouze jednou. Pokud se v adrese nachází více nulových bloku, ˚ lze takto nahradit pouze jeden z nich, jinak by nebylo zjistitelné, jak vypadala puvodní ˚ adresa v nezkráceném tvaru. Napˇríklad následující adresa 123:0:0:0:123:0:0:0 lze zapsat jako 123:: 123:0:0:0 nebo jako 123:0:0:0:123::, ale ne jako 123::123:: v tu chvíli není možné pˇresnˇe urˇcit, jak puvodní ˚ adresa vypadala. Velká variabilita zápisu zpusobila, ˚ že bylo pˇríjato RFC 5952 A Recommendation for IPv6 Address Text Representation. Který definuje kanonický tvar zápisu IPv6 adresy. Pravidla pro vytvoˇrení kanonického tvaru jsou [14]: •
Poˇcáteˇcní nuly v bloku cˇ tveˇrice se musí vždy vynechat.
•
Zápis „::“ se musí použít tak, aby mˇel co nejvˇetší efekt na zkrácení a musí obsáhnout všechny sousedící bloky nul. Je nepˇrípustné nechat „: 0::“ nebo „::0:“. Pokud existují dvˇe stejnˇe dlouhé skupiny nulových bloku, ˚ musí se zkrátit první zleva. Dále není povoleno použít „::“ na jediný nulový blok ten musí zustat ˚ vždy ve tvaru „:0:“. Pro pˇríklad adresa 2001:db8:0:1:1:1:1:1 musí zustat ˚ v tomto tvaru, nelze ji psát jako 2001:db8::1:1:1:1:1. Adresu, která byla použita výše 123:0:0:0:123:0:0:0, lze v kanonickém tvaru zapsat pouze jako 123::123:0:0:0.
•
Poslední pravidlo je psát šestnáctkové cˇ íslice reprezentované písmeny pouze malými znaky. Toto pravidlo je urˇceno také proto, aby nedochá18
3. A NALÝZA IP V 6 KOMUNIKACE zelo k omylum ˚ s nˇekterými potenciálnˇe zamˇenitelnými cˇ íslicemi („0“ a „D“ pˇrípadnˇe „8“ a „B“). ˇ Casto se lze v IPv6 setkat se zápisem cˇ ásti adresy, na jejímž konci je lomítko a za ním cˇ íslo. Tímto zápisem se oznaˇcují prefixy. Prefix vyjadˇruje pˇríslušnost k urˇcité síti a stejný prefix mají všechna rozhraní v dané síti. Délka prefixu muže ˚ být u každé sítˇe jiná, záleží s jakou pˇresností je na nˇej nahlíženo. Krátký prefix muže ˚ znaˇcit urˇcitého poskytovatele Internetu, zatímco delší bude spíše znaˇcit urˇcitou podsít’. Zápis prefixu se rˇídí schématem CIDR (Classless Inter-Domain Routing). A podle nˇej je zápis následovný: IPv6Address/PrefixLength. Délka prefixu oznamuje, kolik bitu˚ od zaˇcátku adresy patˇrí do urˇcitého prefixu. Pokud vypadá adresa tˇreba takto fe80::/10 znamená to, že do prefixu patˇrí prvních 10 bitu. ˚ Názornˇe je to takto: prefix fe80::/10 má zápis v bitové podobˇe 1111111010000000::/10 a z nˇej se vezme prvních 10 bitu˚ 1111111010. Prefix lze vzít i z cˇ ásti bloku. Do tohoto prefixu nepatˇrí tˇreba závˇereˇcná nula, ale musí být napsána. Pokud by nebyla a zápis prefixu by vypadal takto fe8::/10 mˇelo by se za to, že prefix má nezkrácený tvar 0fe8::/10 a vzalo by se z nˇej 10 bitu, ˚ neboli 0000111111 což už není stejný prefix. Samozˇrejmˇe lze napsat i celou adresu a z ní vzít prefix. Jelikož nás pˇri zjišt’ování prefixu nezajímá to, co je za prefixem, tak se bere jako by za prefixem následovaly samé nuly fe80::/10. 3.1.2 Unicast Unicast v sobˇe sdružuje hned nˇekolik typu˚ adres. První a zárovenˇ nejduleži˚ tˇejší jsou global unicast addresses (globální individuální adresy). Tyto adresy zabírají nejvˇetší adresní prostor, i když v souˇcasnosti je jim pˇridˇelen pouze adresní prostor s prefixem 2000::/3 (001 binárnˇe). Tyto adresy identifikují konkrétní uzel v rámci celého Internetu a už podle názvu je jasné, že jsou celosvˇetovˇe jedineˇcné. Jak globální adresy vypadají je vidˇet na obrázku 3.1. Global routing prefix (globální smˇerovací prefix) se skládá z nˇekolika 16 bitových bloku˚ podle toho, kdo dané bloky spravuje. Organizace IANA (Internet Assigned Numbers Authority), která má na starosti celkovˇe adresy, spravuje prvních 16 bitu˚ a je jen na ní, jaké adresy se budou používat. IANA pˇridˇeluje druhých 16 bitu˚ jednomu z RIR (Regional Internet Registry). Celkem jich je 51 . A ti zase pˇridˇelují 33.–48. bit LIR (Local Internet Registry). Tˇemi bývají zpravidla místní poskytovatelé Internetu (ISP Internet service provider). 1. AFRINIC (Afrika), APNIC (Asie and Pacifik), ARIN (Severní Amerika), LACNIC (Latinská Amerika), RIPE NCC (Evropa a Blízký východ)
19
3. A NALÝZA IP V 6 KOMUNIKACE LIR, který má k dispozici urˇcitý prefix, pˇridˇelí koncovým zákazníkum ˚ urcˇ itou cˇ ást prefixu se stejným zaˇcátkem. Tento pˇrístup má zajistit agregaci smˇerovacích údaju, ˚ tak aby byla celá sít’ poskytovatele i s jeho zákazníky popsat konkrétním prefixem. Tato cˇ ást adresy je také nazývaná public topology (veˇrejnou topologií). Druhá cˇ ást je subnet ID (identifikátor podsítˇe) nebo také jinak site topology (místní topologie). Bˇežná délka subnet ID je 16 bitu˚ a umožnuje ˇ tak rozlišit až 65 536 ruzných ˚ podsítí. Tato cˇ ást je pod správou místní sítˇe nejˇcastˇeji u koncového uživatele. Dohromady musí mít global routing prefix spolu s subnet ID 64 bitu. ˚ Je možné setkat se se subnet ID menším, než je udávaných 16 bitu. ˚ V tomto pˇrípadˇe bývá subnet ID 8 bitu˚ nebo muže ˚ být dokonce nulové. ˇ Cást, kterou spravuje LIR je pak o tˇech 8 nebo 16 bitu˚ delší. Tento pˇrístup se používá, pokud není nutno mít tolik podsítí. Za subnet ID následuje interface ID. Další skupinou jsou local addresses (lokální adresy). Lokální adresy jsou zvláštní v tom, že neplatí v celém Internetu, ale pouze v koncových sítích. Formát lokálních adres je na obrázku 3.1. Hlavní skupinu v lokálních adresách tvoˇrí local link addresses (lokální linkové adresy). Local link addresses mají nejvˇetší smysl u vnitˇrních mechanismu˚ IPv6, kde pomocí nich dochází k výmˇenˇe zpráv sloužících ke konfiguraci. Lze je poznat celkem snadno. Mají totiž vyhrazen vlastní prefix, stejnˇe jako jej mˇely v IPv4 (169.254.0.0/16). V IPv6 je prefix fe80::/10. Za tímto prefixem následuje 54 bitu˚ nulových. A na konci následuje interface ID. Prvních 64 bitu˚ adresy se oficiálnˇe tváˇrí jako adresa sítˇe cˇ i podsítˇe, ale neslouží ke smˇerování kvuli ˚ omezení dosahu daného prefixu pouze na linku.2 Výhoda tˇechto adres je v tom, že každý poˇcítaˇc je schopen si je vygenerovat, aniž by vˇedˇel nˇeco o síti, ke které je pˇripojen. V pˇrípadˇe pˇripojení více poˇcítaˇcu˚ tímto zpusobem ˚ v jedné lince, budou schopny v dané síti fungovat pouze na základˇe této adresy a nebudou ke svému provozu potˇrebovat nic kromˇe switche. Router ani DNS server není potˇreba, ale zpusob ˚ komunikace bude znaˇcnˇe komplikovaný kvuli ˚ nutnosti zadávat pˇrímo IPv6 adresy. Druhou skupinou lokálních adres jsou unique local addresses (unikátní lokální). Unique local addresses nahradily site local addresses (lokální místní), které jsou zakázány. Unique local addresses nachází uplatnˇení v pˇrípadech, kdy je potˇreba mít jednu sít’, ale místa, která mají být v síti pˇripojena, nejsou fyzicky na jedné lince. V tomto pˇrípadˇe pˇrichází na rˇ adu právˇe unique local addresses, které pˇriˇradí tˇemto místum ˚ stejný prefix a poˇcítaˇce si potom budou 2. Dosah má smysl pˇredevším pro multicast, kde se mu budu vˇenovat, zde jsem ho pouze zmínil.
20
3. A NALÝZA IP V 6 KOMUNIKACE myslet, že sídlí v jedné fyzické síti. Unique local addresses se poznají podle prefixu fc00::/7. [11] Za tímto prefixem následuje jednobitový pˇríznak L (8. bit), který urˇcuje, zda byl prefix generován lokálnˇe (L=1) nebo jinak (L=0)3 . Jelikož jsou v souˇcasnosti všechny unique local addresses generovány lokálnˇe, tak se dá rˇ íct, že je prefix fd00::/8. Za prefixem následuje 40 bitu˚ tvoˇrících global ID (globální identifikátor), ten je náhodnˇe vygenerován. Za tˇemito 48 bity se nalézá 16bitový subnet ID. A na konci opˇet interface ID. Zámˇernˇe jsem vynechával interface ID (identifikátor rozhraní),protože je stejný v globálních i lokálních adresách. Interface ID je poslední cˇ ást adresy, má konstantní délku 64 bitu˚ a identifikuje konkrétní stroj v rámci podsítˇe. Interface ID je schopen si vygenerovat konkrétní stroj sám nebo mu muže ˚ být pˇridˇelen správcem sítˇe. Záleží, jestli se použije bezstavová konfigurace nebo DHCPv6. V pˇrípadˇe bezstavové konfigurace se pro vygenerování identifikátoru používá modified EUI-64 (modifikované EUI-64) nebo je kryptograficky vygenerován z veˇrejného klíˇce. Nejbˇežnˇejší je první zpusob. ˚ V pˇrípadˇe DHCPv6 je identifikátor pˇridˇelen náhodnˇe. Více se interface ID vˇenuje kapitola 3.3. Poslední skupinu v unicastu tvoˇrí adresy obsahující IPv4 adresy, obrázek 3.1. Tyto adresy muže ˚ využívat nˇejaký pˇrechodový mechanismus, který potˇrebuje vyjádˇrit adresy z IPv4. Tˇechto typu˚ adres vzniklo v historii nˇekolik. První byly IPv4-compatible addresses (IPv4 kompatibilní adresy) ty se skládaly z 96 nulových bitu˚ a za nimi následovala IPv4 adresa. IPv4-compatible addresses byly nahrazeny IPv4-mapped address (IPv4 mapované adresy) ty mˇely prvních 80 bitu˚ nulových, za nimi 16 jednotkových bitu˚ a nakonec IPv4 adresa. V souˇcasnosti se používají IPv4-embedded addresses (adresy s vloženým IPv4). IPv4-embedded addresses je možné rozdˇelit do dvou druhu˚ podle pˇridˇeleného prefixu. První druh umožnuje ˇ vyhradit cˇ ást lokálního prostoru s tím, že 64.–71. bit musí být nulový. Za nˇež pˇrijde IPv4 adresa. U druhého druhu se pˇridˇeluje univerzální prefix 64:ff9b::/96. Pˇri použití druhého zpusobu ˚ je možné napsat IPv4 adresu v jejím obvyklém tvaru (V desítkové soustavˇe s oddˇelenými bajty teˇckou.). Použiji tˇreba adresu 147.230.49.73, která by vypadala následovnˇe 64:ff9b::147.230.49.73. U prvního druhu se musí IPv4 adresa pˇrevézt do tvaru odpovídajícímu IPv6 (64:ff9b::93e6:3149). Zpusob ˚ pˇrevedení do IPv6 tvaru ukážu nyní na pˇríkladu právˇe s IPv4 adresou 147.230.49.73. Každý blok je rozepsán do dvojkového tvaru (na bity). 3. Zatím není specifikováno, ale oˇcekává se, že bude pˇridˇelován nˇejakou autoritou.
21
3. A NALÝZA IP V 6 KOMUNIKACE 10010011.11100110.00110001.01001001 Následnˇe jsou bity uskupeny do cˇ tveˇric a potom pˇrevedeny do šestnáctkové soustavy. Ve výsledku adresa 147.230.49.73 vypadá následovnˇe 93e6: 3149. Global Unicast Address 45 bits
3 bits
001
16 bits
Global Routing Prefix
Subnet ID
Public topology
Site topology
Link Local Address 54 bits
10 bits
1111111010 000000000000000000000000000000000000000000000000000000 fe80::/10
Unique Local Address 16 bits
40 bits
1 bit
7 bits
1111110 L
Global ID
Subnet ID
fc00::/7 64 bits
Interface ID Interface identifier
IPv4-embedded Address 32 bits
96 bits
IPv4 Address
Prefix
Obrázek 3.1: Typy unicastových adres
3.1.3 Multicast Multicast slouží k odeslání dat skupinˇe uzlu. ˚ Ale na rozdíl od unicastu pˇri poslání více poˇcítaˇcum ˚ projde linkou pouze jednou (U unicastu by se data odeslala tolikrát, kolik by bylo žadatelu.). ˚ Hlavní využití nachází pˇredevším u streamování televizního vysílání, internetových rádií a videokonferencí v reálném cˇ ase. Multicast není žádnou novinkou v IPv6, nebot’ se úspˇešnˇe používá již v IPv4. Základní formát multicastové adresy je zobrazen na obrázku 3.2 8 bits
4 bits
4 bits
11111111 0 R P T Scope
112 bits
Group ID
ff00::/8
Obrázek 3.2: Formát multicastové adresy
22
3. A NALÝZA IP V 6 KOMUNIKACE Že se jedná o multicastovou adresu se pozná podle prvního bajtu, ten je ff a tvoˇrí obecný prefix ff00::/8. Za ním následuje cˇ tveˇrice jednobitových pˇríznaku, ˚ ty dále konkretizují použití a formát adresy. První pˇríznak je rezervován pro pozdˇejší použití a musí být nastaven na nulu. Za pˇríznaky je pole scope (dosah). Scope má délku 4 bity a urˇcuje jaký rozsah pusobnosti ˚ má daná multicastová skupina, viz. obrázek A.2. Na konci adresy je group ID (Adresa skupiny), ta má délku 112 bitu˚ a její tvar je závislý na pˇríznacích, proto se jimi budu zabývat souˇcasnˇe. Dosah adres se používá k nastavení rozsahu pusobnosti ˚ adres a vymezuje topologickou oblast, v níž je multicastové adresa jednoznaˇcná. Definovaných hodnot rozsahu je 9 a 3 z nich jsou rezervované. Dalších 7 hodnot je volnˇe k dispozici a ISP nebo správce sítˇe s nimi muže ˚ volnˇe nakládat, ale mˇel by zachovat urˇcité cˇ lenˇení, kde vˇetší cˇ íslo znamená dosah do vˇetší cˇ ásti Internetu. Takže by se nemˇelo stát, že správce sítˇe v nˇejaké organizaci nastaví dosah adresy urˇcené pro urˇcité místo (Site scope) nad hodnotu 8. Dobˇre je vidˇet jak by takové cˇ lenˇení dosahu mˇelo vypadat na obrázku A.3. Z obrázku je patrné, že v nˇem jsou urˇcité zóny podle dosahu, a je vidˇet, že zóny o stejném rozsahu se nepˇrekrývají a zóny s nižším rozsahem nepˇrekroˇcí hranici zóny s vˇetším rozsahem. Co konkrétnˇe znamenají jednotlivé dosahy, které jsou pˇresnˇe specifikovány, popíšu nyní. •
1 (Interface) – Tento dosah nepˇrekroˇcí jediné rozhraní (PC). Jeho využití je pro loopback(lokální smyˇcka).
•
2 (Link) – Tento dosah nepˇrekroˇcí konkrétní fyzickou sít’ (napˇr. ethernet). Tento dosah by se dal pˇrirovnat k bˇežné domácnosti.
•
4 (Admin) – První dosah který musí být již nakonfigurován správcem, muže ˚ totiž obsahovat více než jednu linku. Zpravidla se jedná o podsít’.
•
5 (Site) – Tento dosah pˇredstavuje cˇ ást sítˇe v organizaci, která se nachází v jedné geografické lokalitˇe. Pˇríkladem mohou být jednotlivé fakulty univerzity.
•
8 (Organisation) – Pokrývá nˇekolik míst náležejících jedné organizaci. Napˇríklad celá univerzita nebo firma s poboˇckami v ruzných ˚ mˇestech.
•
e (Global) – Celosvˇetový dosah (celý Internet).
Základním pˇríznakem je pˇríznak „T“ (transient). Tento pˇríznak definuje, zda je daný group ID pˇridˇelen trvale nebo doˇcasnˇe. Pokud je T=0, znamená to, že se jedná o trvalou neboli well-known adresu. Tyto adresy pˇridˇeluje 23
3. A NALÝZA IP V 6 KOMUNIKACE IANA. Pokud je ovšem T=1, tak se jedná o doˇcasnou adresu, kterou si mohou vygenerovat všichni podle potˇreby. V pˇrípadˇe trvalé skupiny je group ID stále platný a nezávislý na dosahu. Jako ukázka muže ˚ posloužit komunikace s routery. Pokud poˇcítaˇc chce komunikovat s routery, používá multicastovou adresu ve tvaru ff0x::2, kde x pˇredstavuje ruzné ˚ dosahy. Pokud poˇcítaˇc zašle dotaz na ff02::2, tak se bude týkat pouze routeru, ˚ kteˇrí sídlí na lince. Na adrese ff08::2 jsou to už všechny routery v dané organizaci, ale poˇrád je to adresa vyhrazená pro zaslání na všechny routery. Zatímco, pokud by byla multicastová adresa ve tvaru tˇreba ff12::2, tak nemá žádnou spojitost s adresou ff02::2 (všechny routery na lince) ani s pˇrípadnou stejnou adresou ovšem vytvoˇrenou jinde. Dokonce nemá žádný vztah s adresou, která by byla stejná až na dosah (napˇr. ff1e::2). T=1 má svuj ˚ význam ještˇe navíc v souvislosti s ostatními pˇríznaky. Pˇríznak „P“ znaˇcí adresy, které vznikají z unicastové adresy (tzv. UnicastPrefix-based IPv6 multicast addresses). [9] Pokud je P=1 tak musí být i T=1 jelikož se jedná o doˇcasnou skupinu. Úˇcelem tˇechto adres má být zajištˇení snazšího generování adres, aniž by se muselo komplikovanˇe zjišt’ovat, jestli daná adresa již nˇekde neexistuje. To je zaruˇceno vložením prefixu unicastových adres z dané sítˇe. Pˇríznak „P“ definuje jiný tvar group id. Tvar adres založených na unicastu je zobrazen na obrázku 3.3. U tˇechto adres následuje za dosahem 8bitové pole reserved se všemi bity nulovými a další 8bitové pole plen (délka prefixu). To znamená, že prefix muže ˚ mít maximální délku 64 bitu. ˚ Unicast-Prefix-based IPv6 Multicast Address 8 bits
4 bits
4 bits
8 bits
11111111 0 R 1 1 Scope Reserved =0
8 bits
Plen
max. 64 bits
Network prefix
max. 32 bits
Group ID
ff30::/12
Source Specific Multicast address 8 bits
4 bits
4 bits
8 bits
11111111 0 R 1 1 Scope Reserved =0
8 bits
Plen =0
64 bits
Network prefix =0
32 bits
Group ID
ff30::/12
Link-Scoped IPv6 Multicast address 8 bits
4 bits
4 bits
8 bits
11111111 0 R 1 1 Scope Reserved =0
8 bits
Plen =ff
64 bits
Interface ID
32 bits
Group ID
ff30::/12
Obrázek 3.3: Multicastové adresy vzniklé z unicastu. Do adres definovaných pˇríznakem „P“ spadají Source Specific Multicast 24
3. A NALÝZA IP V 6 KOMUNIKACE (SSM) adresy, obrázek 3.3. Tyto adresy mají využítí u pˇrenosu dat z jednoho zdroje skupinˇe pˇríjemcu, ˚ napˇr. u internetového rádia a televize. SSM adresy mají pˇridˇelen prefix ff3x::/96 (x znaˇcí ruzný ˚ dosah) a 32bitové group ID. Jednoznaˇcnost je zaruˇcena pomocí skupinové adresy a zdrojovou adresou odesílatele. Další skupinou adres jsou Link-Scoped IPv6 Multicast addresses (adresy vycházející z rozhraní), 3.3. Dosah nesmí být vˇetší než za linku (hodnota scope je 0-2). Výhoda tˇechto adres je, že si je muže ˚ generovat každý poˇcítaˇc a protože souˇcástí této adresy je i interface ID daného stroje, tak nehrozí konflikt s adresami generovanými sousedy. Délka prefixu má hodnotu ff (64bitová délka interface ID). A posledních 32 bitu˚ náleží group ID. Zatím poslední definovaný pˇríznak multicastu „R“ skrývá jeden další typ adres Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (adresa obsahující shromaždištˇe, rendezvous point, RP).[10] RP adresa vychází z adresy založené na unicastu. Její tvar je na obrázku 3.4. Zmˇena je hlavnˇe v poli RIID (RP Interface ID). Toto pole obsahuje poslední 4 bity z interface ID. A podobnˇe jako u pˇredchozích adres, i zde je potˇreba, aby když R=1 tak i P=1 a T=1. Hlavní úlohu v nˇem hraje tzv. shromaždištˇe (RP), kde je umístˇen distribuˇcní strom skupiny. Výhodou tˇechto adres je jednoduché vytváˇrení jednoznaˇcných adres, protože jediné co je nutné, je udržet si poˇrádek v adresách pouze v rámci shromaždištˇe. Dále možnost odvodit si adresu shromaždištˇe z multicastové adresy a tím pádem i místo kde se do skupiny pˇrihlásit. Embedding the Rendezvous Point Address 4 bits
8 bits
64 bits
11111111 0 1 1 1 Scope Res=0 RIID
Plen
Network prefix
8 bits
4 bits
4 bits
4 bits
32 bits
Group ID
ff70::/12
Obrázek 3.4: Adresa obsahující shromaždištˇe, Rendezvous point, RP Multicastová adresa se nemuže ˚ vyskytovat na místˇe odesílatele datagramu a nesmí se také vyskytovat v rozšiˇrující hlaviˇcce Routing. 3.1.4 Anycast Anycast tvoˇrí novinku v adresaci. Funguje zpusobem, ˚ který umožní, aby se za jednu adresu schovalo více stroju˚ (jako v multicastu), ale datagram byl doruˇcen pouze jednomu konkrétnímu stroji. Základní princip fungování anycastu spoˇcívá ve standardních smˇerovacích principech. Pomocí nich je zajištˇeno, že dotaz doputuje k nejbližšímu stroji ze skupiny provozující 25
3. A NALÝZA IP V 6 KOMUNIKACE danou službu. Nejlepší pˇríklad anycastu jsou DNS servery. Koˇrenových DNS serveru˚ je 13 a za jejich adresami se skrývá pˇribližnˇe 250 serveru˚ rozmístˇených všude možnˇe po sítí. Tímhle je zajištˇeno, že dotaz odeslaný na anycastovou adresu doputuje k nejbližšímu serveru. Ve výsledku dochází k rovnomˇernˇejšímu rozdˇelení zátˇeže, protože z urˇcité oblasti dorazí dotaz k urˇcitému serveru. Tenhle princip umožní kromˇe rozdˇelení zátˇeže rychlejší odezvu díky kratší cestˇe mezi klientem a serverem, zvýšení výkonu a spolehlivosti služby a lepší odolnost vuˇ ˚ ci DoS (Denial of Service) a DDos (Distributed Denial of Service) útokum. ˚ Protože útoˇcníci nejsou schopni dosáhnout dál než na servery, které obsluhují oblast, ve které se nacházejí. Spolehlivost služby je zajištˇena tím, že v pˇrípadˇe výpadku nejbližšího stroje s danou anycastovou adresou, je schopen jeho cˇ innost pˇrevzít jiný stroj ze skupiny, i když na nˇej bude vyvíjena vˇetší zátˇež. Ne vždy je to tak ovšem jednoduše možné. Využití anycastu snižuje i poˇcet adres na nichž je daná služba poskytována. Dobrý pˇríklad jsou DNS servery. U nich by nebylo moc dobré, kdyby mˇel seznam adres koˇrenových DNS serveru˚ nˇekolik stovek položek, z nichž by se pravidelnˇe každý mˇesíc nˇekolik mˇenilo. Anycastové adresy nemají pˇridˇeleno vlastní adresní spektrum a jsou brány z unicastových adres. Tím pádem nelze poznat, zda se jedná o anycastovou nebo unicastovou adresu. Zajímavˇejší je to uvnitˇr této skupiny (sítˇe). Skupina má vlastní prefix sítˇe, který musí obsáhnout všechna rozhraní v této anycastové skupinˇe. To znamená, že pokud se všechny rozhraní nalézají v jedné podsíti, bude jako prefix použita adresa této podsítˇe. Na druhou stranu mohou být cˇ lenové skupiny rozmístˇeny tak nešt’astnˇe, že prefix bude pouze 2000::/3. Rozsah skupiny má zásadní vliv na konfiguraci. Uvnitˇr každé sítˇe, ve které se nalézá anycastová skupina, musí mít anycastová adresa svuj ˚ vlastní smˇerovací záznam, který v jednotlivých routerech ukazuje vždy na nejbližšího cˇ lena skupiny. V pˇrípadˇe prefixu 2000::/3 by mˇelo za následek, pˇridání adresy mezi globální smˇerovací informace. Tudíž potenciálnˇe extrémní navýšení smˇerovacích tabulek uvnitˇr páteˇrních routeru. ˚ Z tohoto duvodu ˚ je použití globálních anycastových adres silnˇe omezeno. Zajímavé použití pˇredstavuje anycast v rámci jediné podsítˇe. Zde neplatí pravidlo o doruˇcení k nejbližšímu cˇ lenovi, protože všichni cˇ lenové jsou z pohledu smˇerování stejnˇe daleko. Ale pˇredstavuje systém, kdy uvnitˇr podsítˇe poskytují cˇ lenové konkrétní služby a je jedno se kterým z tˇechto cˇ lenu˚ chce poˇcítaˇc komunikovat. Tyto anycastové adresy mají podobu pevnˇe definovaných interface ID za prefixem dané podsítˇe. V souˇcasnosti jsou definovány zatím jen dvˇe takovéto adresy jedna ve tvaru samých nul v interface ID pro všechny routery v podsíti. A druhá s tvarem interface ID 26
3. A NALÝZA IP V 6 KOMUNIKACE fdff:ffff:ffff:fffe, která je urˇcena pro home agents, jejichž využití se týká mobility. Bohužel i anycast trpí neduhy. Nejvýznamnˇejší problém se týká stavových protokolu, ˚ pˇredevším TCP a služeb uchovávajících si stavy na serverech. Problém muže ˚ nastat pˇri zasílání série dat na anycastovou adresu. Kdy pˇri výpadku jednoho serveru sice data budou proudit na jiný server, ale ten v pˇrípadˇe stavové služby nemusí mít uložen stav dotyˇcného komunikujícího poˇcítaˇce. V pˇrípadˇe TCP pak nastává problém, když cˇ ást dat dorazí k jednomu cˇ lenovi skupiny a další cˇ ást dat jinému. Tím vznikne zbyteˇcnˇe velký provoz na síti, z duvodu ˚ vyžádání znovu-zaslání dat. Tento problém by šel rˇešit zpusobem, ˚ kdy by odesílatel na poˇcátku pomocí anycastu zjistil unicastovou adresu a na tu potom smˇeroval svou komunikaci. Tím by ovšem ztratil anycast svuj ˚ smysl a byl by zranitelnˇejší i v pˇrípadˇe DoS a DDoS utoku. Další problém se ukrývá pˇrímo v páteˇrních internetových routerech. Ty vˇetšinou odmítají pˇríliš dlouhé prefixy a tedy i záznamy pro anycastové adresy. Dále pˇri zmˇenách ve skupinˇe, mohou být zmˇeny následnˇe vyhodnoceny jako chyba na stranˇe zaˇrízení a poté bude daná adresa zablokována. Nejlepší využití najde anycast u služeb, kde nejsou stavové informace potˇreba jako výše zmínˇený DNS, kdy každý dotaz a odpovˇed’ je zaslán v jednom datagramu a je jedno ke kterému DNS serveru se dotaz dostane. 3.1.5 Povinné adresy uzlu Na zaˇcátku kapitoly bylo zmínˇeno, že každé rozhraní musí mít více adres a na každé pˇrijímat komunikaci. Což je pˇrímo dáno ve specifikaci. To vše z duvodu ˚ ruzných ˚ mechanismu, ˚ které posílají data na ruzné ˚ adresy. Povinné adresy musí mít poˇcítaˇc následující [22]: •
Lokální linková adresa pro každé rozhraní
•
Všechny individuální a výbˇerové adresy, které mu byly pˇridˇeleny
•
Lokální smyˇcka (loopback)
•
Skupinové adresy pro všechny uzly
•
Skupinová adresa pro vyzývaný uzel pro všechny pˇridˇelené individuální a výbˇerové adresy
•
Všechny skupinové adresy, jejichž je cˇ lenem
Další kdo musí pˇrijímat na více adresách, je router. Ten se musí hlásit ke stejným adresám jako poˇcítaˇc. A ještˇe navíc k tˇemto dalším dvˇema: 27
3. A NALÝZA IP V 6 KOMUNIKACE •
Výbˇerová adresa pro smˇerovaˇce v podsíti (pro každé rozhraní, kde funguje jako smˇerovaˇc)
•
Skupinové adresy pro všechny smˇerovaˇce
3.2
Neighbor discovery
Neighbor discovery neboli objevování sousedu˚ slouží v protokolu IPv6 k rˇ ešení jednoho známého problému poˇcítaˇcových sítí. Tímto problémem je, jak poslat data nˇekomu kdo sídlí ve stejné lokální síti (napˇríklad ethernetu) a jediné co znám je IP adresa daného stroje. K tomu aby šla data odeslat, nestaˇcí znát pouze IP adresu, ale je potˇreba znát fyzickou adresu stroje, kterému se mají data odeslat. A to právˇe rˇ eší Neighbor discovery. IPv4 k tomuto úˇcelu používal samostatný protokol ARP (Address Resolution Protocol). Ten fungoval principem, že odeslal dotaz „Kdo je vlastníkem této IP adresy“ na broadcastovou adresu 255.255.255.255. Stroj, který má danou adresu, odesílateli odpovˇedˇel a pˇriložil k odpovˇedi svou fyzickou adresu. V IPv6 je tento mechanismus definován v RFC 4861 Neighbor Discovery for IP version 6 (IPv6) jako základní souˇcást IP protokolu. A na rozdíl od ARPu v IPv4, který rˇ ešil pouze hledání linkových adres, neighbor discovery rˇ eší další problémy: •
Zjišt’ování linkových adres v jedné lokální síti
•
Aktualizace a zjišt’ování zmˇen v linkových adresách
•
Hledání smˇerovaˇcu˚
•
Zjišt’ování parametru˚ sítˇe a údaju˚ pro automatickou konfiguraci
•
Dosažitelnost souseda
•
Detekce duplicit
Pro svoji cˇ innost využívá neighbor Discovery sedm typu˚ ICMP zpráv. Pˇet z nich jsou: •
Neighbor solicitation message (Výzva sousedovi)
•
Neighbor advertisement message (Ohlášení souseda)
•
Router solicitation message (Výzva smˇerovaˇci)
•
Router advertisement message (Ohlášení smˇerovaˇce)
•
Redirect (Pˇresmˇerování) 28
3. A NALÝZA IP V 6 KOMUNIKACE Zbylé dvˇe slouží pro bezpeˇcnost respektive pro bezpeˇcné objevování sousedu˚ neboli SEND (SEcure Neighbor Discovery) •
Certification path solicitation (Žádost o certifikaˇcní cestu)
•
Certification path advertisement (Ohlášení certifikaˇcní cesty)
3.2.1 Zjišt’ování linkových adres Zjišt’ování linkových adres vychází pˇrímo z ARP protokolu. Zmˇeny nastaly pouze u názvu˚ a adresy, na kterou se zasílá výzva. Pro tento mechanismus se vyhradila skupina multicastových adres na které se zasílají výzvy. Tyto adresy mají spoleˇcný prefix ff02:0:0:0:0:1: ff00::/104. Za tento prefix pˇripojí uzel hledající linkovou adresu urˇcitého uzlu posledních 24 bitu˚ z hledané IP adresy. V pˇrípadˇe, že hledá linkovou adresu pro uzel s IP adresou fe80::1234:5678 vezme cˇ ást 34:5678 a pˇripojí jí za daný prefix. Ve výsledku bude zasílat svuj ˚ dotaz této multicastové adrese ff02::1:ff34:5678. Pokud poˇcítaˇc bude shánˇet linkovou adresu poˇcítaˇce, u nˇejž zná pouze IP adresu, bude postup následovný. Vytvoˇrí ICMP zprávu neighbor solicitation (NS) obr. 3.5 a odešle jí na IP adresu, kterou vytvoˇrí podle postupu v pˇredchozím odstavci. Souˇcástí NS muže ˚ být i volba, obr. A.4, která ohlašuje linkovou adresu odesílatele, aby pˇríjemce rovnou vˇedˇel, kam má zaslat odpovˇed’ a nemusel sám ještˇe zjišt’ovat linkovou adresu tazatele. 8 bits
0 bits
Type = 135
16 bits
Code = 0
24 bits
32 bits
Checksum Reserved = 0
Target address
Options
Obrázek 3.5: ICMP zpráva Neighbor solicitation (NS, Výzva sousedovi) Odeslaná výzva se dopraví ke každému uzlu v síti, a pokud není pˇríjemce tím, kdo je hledán, tuto výzvu ignoruje. Uzel, jehož posledních 24 bitu˚ v IP adrese se shoduje s koncem multicastové adresy, vytvoˇrí ICMP zprávu neighbor advertisement (NA), obr. 3.6, a do voleb pˇridá svou vlastní linkovou adresu. Tuto zprávu poté odešle už pˇrímo dotazujícímu se uzlu a ten si uloží linkovou adresu do své cache sousedu. ˚ V NA se nacházejí 3 pˇríznaky routing 29
3. A NALÝZA IP V 6 KOMUNIKACE flag, solicitation flag a override flag. Tyto pˇríznaky urˇcují, jestli je odesílatel router (routing flag) nebo jestli je odesílání NA vyžádané (solicitation flag), pˇrípadnˇe zda má toto ohlášení pˇrepsat existující údaje uložené v cache sousedu˚ (override flag). 8 bits
0 bits
Type = 136
16 bits
Code = 0
24 bits
32 bits
Checksum Reserved = 0
R S O
Target address
Options
Obrázek 3.6: ICMP zpráva Neighbor advertisement (NA, Ohlášení souseda) Uzel muže ˚ sám od sebe zaslat nevyžádanou NA zprávu. To dˇelá v pˇrípadˇe, že u nˇej došlo ke zmˇenˇe linkové adresy a chce o tom dát okolí vˇedˇet. Potom zašle nˇekolik NA na multicastovou adresu ff02::1, na které poslouchají všechny uzly v síti. Ty uzly, které mají ve své cache sousedu˚ záznam s danou IP adresou odesílatele ohlášení, si daný záznam aktualizují a ostatní zprávu ignorují. 3.2.2 Zjišt’ování dosažitelnosti souseda Pˇri práci se sousedy si každý uzel udržuje aktuální stav dosažitelnosti tˇech, se kterými komunikuje. Dosažitelnost se urˇcuje dvˇema zpusoby. ˚ První zpusob ˚ je, že vyšší vrstva potvrdí dosažitelnost, pokud probíhá komunikace. Druhý zpusob ˚ je, že uzel zjišt’uje dosažitelnost vlastními silami. Základ neighbor unreachability detection, tvoˇrí pˇet ruzných ˚ stavu˚ v cache sousedu, ˚ které jsou u každé položky a urˇcují, v jaké fázi dosažitelnosti se konkrétní uzel nachází. První stav incomplete se vyskytuje pouze na poˇcátku zjišt’ování dosažitelnosti a oznamuje, že soused byl zrovna pˇridán do cache sousedu˚ a už podle názvu incomplete (nekompletní) je jasné, že nˇeco chybí. Pˇresnˇeji, když se uzel nachází v tomto stavu, tak mu byla zaslána ICMP zpráva NS a dosud nedorazila odpovˇed’ NA. Jakmile dorazí odpovˇed’, tak se hodnota zmˇení z incomplete na reachable (dosažitelná). Pokud by odpovˇed’ nedorazila, znamená to, že daný uzel není dosažitelný a položka o nˇem bude z cache sousedu˚ vymazána. Stav reachable je ideální a znamená, že dostupnost byla nedávno potvrzena a s daným uzlem je možné bez problému komunikovat. Tento stav není 30
3. A NALÝZA IP V 6 KOMUNIKACE trvalý. Doba, po kterou je daný uzel považován za dosažitelný, se urˇcuje v každé síti pomocí router advertisement. Pokud tato doba uplyne dˇríve, než staˇcí pˇrijít nové potvrzení o dosažitelnosti, mˇení se hodnota stavu na stale (prošlá). Stav stale ještˇe neznamená, že je nˇeco špatnˇe. Znaˇcí to jen, že s daným uzlem nebylo chvíli komunikováno. V tomto stavu zustává ˚ záznam v cache sousedu˚ do té doby než je potˇreba odeslat uzlu nˇejaká data. Když je potˇreba data odeslat, odešlou se stejnˇe, jako by byl daný uzel dosažitelný a provede se zmˇena stavu na delay (odložená). Ve stavu delay se nachází uzel do té doby, než vyšší vrstva potvrdí, že dorazila odpovˇed’ a potom se stav zmˇení na reachable. [16] Nebo odpovˇed’ nedorazí a uzel bude muset zjistit dosažitelnost vlastními silami na IP vrstvˇe a pˇritom zmˇení stav na probe (testovaná). Ve stavu probe se dosažitelnost zjišt’uje stejnˇe jako ve stavu incomplete a to pomocí zpráv NS a NA z principu hledání linkových adres. V tomto pˇrípadˇe zašle uzel nˇekolik NS, a když dostane odpovˇed’ v podobˇe NA, tak zmˇení stav na reachable. Pokud se odpovˇedi nedoˇcká, považuje uzel za nedosažitelný a je odstranˇen z cache sousedu. ˚ Jak muže ˚ vypadat cache sousedu, ˚ je vidˇet na obr. A.5.
3.3
Autokonfigurace
Pokud chce stroj pˇripojený k síti komunikovat, musí mít pˇridˇelenou adresu. V pˇrípadˇe lokální komunikace mu postaˇcuje, aby si sám vygeneroval local link address pomocí modified EUI-64. V pˇrípadˇe komunikace v Internetu potˇrebuje mít adresu, která bude pˇrístupná z Internetu. K tomu potˇrebuje mít pˇridˇelen prefix sítˇe, ve které se nachází a znát další informace nutné pro komunikaci. Tyto informace jsou mu poskytnuté pomocí autokonfigurace. Autokonfigurace zná dva zpusoby ˚ jak poˇcítaˇci tyto informace poskytnout. [1] První zpusob ˚ je bezstavová konfigurace stateless configuration. Druhý zpu˚ sob se jmenuje stavová konfigurace (statefull configuration) pomocí DHCPv6. Výraz stavová konfigurace se ovšem moc nepoužívá a místo nˇej se hovoˇrí pouze o DHCPv6. 3.3.1 Bezstavová konfigurace Základním mechanismem v bezstavové autokonfiguraci je router advertisement (RA, Ohlášení smˇerovaˇce). RA odesílá každý router do všech sítí ke kterým je pˇripojen. Odesílání probíhá v náhodných intervalech, aby se zamezilo odeslání ohlášení z více routeru˚ ve stejnou dobu, což by mohlo mít 31
3. A NALÝZA IP V 6 KOMUNIKACE za následek zmatek v síti. RA obsahuje informace o síti a musí je pˇrijímat každý uzel v dané síti a rˇ ídit se podle nˇej. Formát RA je vidˇet na obrázku 3.7. 8 bits
0 bits
16 bits
24 bits
Type = 134
Code = 0
Checksum
Cur Hop Limit
M O H Reserved = 0
Router Lifetime
32 bits
Reachable Time Retrans Timer Options
Obrázek 3.7: Router advertisement (RA, Ohlášení smˇerovaˇce) RA je informaˇcní typ ICMP zprávy. Pole type (typ) urˇcuje, o jaký typ zprávy se jedná. RA má v tomto poli hodnotu 134. Pole code (kód) obsahuje implicitnˇe hodnotu 0. A pole checksum (kontrolní souˇcet) slouží jako kontrola, že paket došel v poˇrádku. Cur hop limit oznamuje jakou hodnotu má odesílající uzel ze sítˇe vložit do pole hop limit v základní hlaviˇcce. Za tímto polem následuje nˇekolik pˇríznaku. ˚ Pˇríznak „M“ neboli managed address configuration (Stavová konfigurace adres) oznamuje, zdali se má pro konfiguraci použít DHCPv6, v pˇrípadˇe hodnoty 1, pokud je hodnota v pˇríznaku 0 použije se bezstavová konfigurace. Pokud se má použít DHCPv6, tak se hodnota v dalším pˇríznaku ignoruje. Další pˇríznak je „O“ (other stateful configuration). Other stateful configuration (stavová konfigurace ostatních parametru) ˚ oznamuje, že pro nastavení nˇekterých parametru˚ se použije bezstavová konfigurace, napˇr. pro adresy, prefix, smˇerování. A pro jiné parametry se má použít DHCPv6 napˇr. pro adresy lokálních DNS serveru. ˚ To vše pokud je hodnota v poli 1. Pokud je hodnota 0 tak se veškeré parametry nastavují bezstavovˇe. Pˇríznak „H“ znaˇcí home agent (domácí agent). A router tímto pˇríznakem oznamuje, že je ochoten fungovat jako home agent pro mobilní uzel. Tento pˇríznak má smysl pouze pro mobilitu. Router lifetime (životnost implicitního smˇerovaˇce). Tímto polem router oznamuje v sekundách jak dlouho je ještˇe ochoten fungovat jako implicitní router pro uzly pˇripojené v síti. Pokud je hodnota 0, znamená to, že router nemá být používán jako implicitní. Další pole reachable time (trvání dosažitelnosti) oznamuje, jak dlouho má být uzel považován za dosažitelný od posledního zjištˇení dosažitelnosti. Pole retrans timer (interval opakování) pro zmˇenu urˇcuje dobu mezi dvˇema odesláními NS. Tyto pole nacházejí hlavní uplatnˇení v neighbor unreachability 32
3. A NALÝZA IP V 6 KOMUNIKACE detection. Posledním polem je options (volby). V tomto poli jsou obsaženy ruzné ˚ volby pro nastavení ostatních parametru˚ konfigurace, jako jsou napˇr. nastavení prefixu a lokálních DNS serveru. ˚ Pokud chce ovšem poˇcítaˇc komunikovat po pˇripojení k síti. Musí mít svou vlastní adresu. Autokonfigurace byla navržena tak, aby si každý uzel mohl vygenerovat svou lokální adresu (local link address). Local link address je tvoˇrena prefixem fe80::/10 a interface ID. [17] Prefix je pevnˇe daný. Proto poˇcítaˇci staˇcí si vygenerovat pouze interface ID. K tomuto se využívá modifikované EUI-644 . K vytvoˇrení interface ID pomocí modifikovaného EUI-64 postaˇcí poˇcítaˇci pouze MAC adresa jeho sít’ové karty, která se pomocí jednoduchého algoritmu pˇrevede. Postup ukážu na konkrétním pˇríkladu s MAC adresou 00:5f:47:dd:b8:c9. MAC adresa se rozdˇelí na 2 pulky ˚ 00:5f:47 a dd:b8:c9. Mezi nˇe se vloží ff:fe a odstraní se oba krajní symboly :. V tuto chvíli má identifikátor tvar 005f:47ff:fedd:b8c9. Nyní se musí ještˇe invertovat 7. bit, který je také oznaˇcován jako global flag (globální pˇríznak). 1 znamená globální jednoznaˇcnost a 0 lokální5 . Výsledná adresa tedy vypadá takto 025f:47ff: fedd:b8c9. Celý postup je ještˇe zobrazen na obrázku 3.8.
0 0 :5 f : 4 7 : d d: b 8 : c 9
0000 0000 0101 1111 0100 0111 1101 1101 1011 1000 1100 1001
0000 0010 0101 1111 0100 0111 1111 1111 1111 1110 1101 1101 1011 1000 1100 1001
0 2 :5 f : 4 7 f f : f e d d: b 8 : c 9 Obrázek 3.8: Modifikované EUI-64
Bylo by vhodné zmínit, jak je zaruˇceno, že 7. bit bude mít hodnotu 1. V principu je to jednoduché. Všechny MAC adresy mají od výrobce nastavenou 4. V adresaci jsem zmínil ještˇe kryptograficky generovaný Interface ID, ale ten se prakticky nepoužívá. 5. Zde je vhodné upozornit na jednu vˇec. Podle klasického EUI-64 je pˇri globální jednoznaˇcnosti 7.bit nulový. Jednoduše tedy 0 = globální a 1 = lokální. IPv6 používá ovšem modifikované EUI-64, kde je to pˇresnˇe naopak.
33
3. A NALÝZA IP V 6 KOMUNIKACE hodnotu na 7. bitu na 06 . V MAC adrese se proto vyskytují na druhém místˇe pouze znaky 0,1,4,5,8,9,c,d. Ty se pˇri modifikovaném EUI-64 mˇení popoˇradˇe na 2,3,6,7,a,b,e,f. Proti používání EUI-64 je rˇada ochráncu˚ soukromí, protože je možné podle nˇej identifikovat konkrétní uživateluv ˚ poˇcítaˇc. Po vygenerování lokální adresy, musí poˇcítaˇc pomocí NS zjistit, zda je jediný, kdo má tento interface ID v rámci sítˇe. Nemˇelo by se stávat, aby v jedné síti sídlilo více uzlu˚ se stejnou adresou, ale není to vylouˇceno, jelikož si MAC adresu muže ˚ každý zmˇenit podle svého. Navíc nˇekteˇrí výrobci dávají v základu všem sít’ovým kartám MAC adresu 00:00:00:00:00:00, a uživatel si potom musí nastavit pomocí dodávaného softwaru novou MAC adresu. Tomuto principu se rˇ íká detekce duplicit. 8 bits
0 bits
Type = 133
16 bits
Code = 0
24 bits
32 bits
Checksum Reserved = 0
Options
Obrázek 3.9: Router solicitation (RS, Výzva smˇerovaˇci) Pokud detekce duplicit dopadne dobˇre, poˇcká pˇripojený uzel než router zašle RA, aby si mohl nastavit parametry, protože zatím o síti neví nic. Nebo muže ˚ být poˇcítaˇc aktivní a vyžádat si zaslání RA. To udˇelá pomocí zaslání ICMP zprávy router solicitation (RS, Výzva smˇerovaˇci) na adresu ff02::2, což je multicastová adresa pro routery s link-local dosahem. Formát zprávy RS je vidˇet na obrázku 3.9. Souˇcástí této zprávy je jeho linková adresa (obr. A.4), kterou umístí do pole options. Router mu odpoví odesláním RA (obrázek 3.7), jehož souˇcástí je nˇekolik voleb, podle kterých si poˇcítaˇc nastaví parametry pˇripojení a to bud’ bezstavovˇe nebo pomocí DHCPv6. První volba je povinná a tou je linková adresa routeru (obrázek A.4). Druhou volbou muže ˚ router oznámit maximální MTU používané v dané síti. Formát této volby je na obrázku A.6. Dále by mˇel router pˇridat volbu pro každý prefix používaný v dané síti. Z toho vyplývá, že se od zaˇcátku poˇcítalo, že jedna fyzická sít’, muže ˚ sloužit nˇekolika logickým sítím a tudíž mít i nˇekolik prefixu. ˚ Formát této volby je vidˇet na obrázku A.7. Nejvýznamnˇejší pole v této volbˇe jsou samozˇrejmˇe prefix a prefix length (délka prefixu). V poli prefix je uložen vlastní prefix sítˇe v délce 128 bitu. ˚ 6. Vyzkoušeno na vzorku pˇribližnˇe 40 ethernetových a 20 wifi karet.
34
3. A NALÝZA IP V 6 KOMUNIKACE Pole prefix length oznamuje kolik bitu˚ z prefixu je platných. Standardnˇe by to mˇelo být 64 bitu. ˚ Za prefix length následují pˇríznaky „L“, „A“ a „R“. Pˇríznak „L“ znaˇcí on-Link (na lince). Tento pˇríznak slouží k rozhodování, který uzel je lokální a tudíž dosažitelný linkovou vrstvou. Druhý prefix „A“ autonomous address-configuration (autonomní konfigurace adres) oznamuje, zda lze prefix použít k bezstavové konfiguraci. Pokud je pˇríznak nastaven na 0, uzly v síti nemohou daný prefix konfigurovat bezstavovˇe a jsou odkázány pouze na DHCPv6. Pˇríznak „R“ router address (adresa smˇerovaˇce) má využití pouze pro mobilitu. Pokud má tento pˇríznak hodnotu 1, znamená to, že v poli prefix se nalézá kompletní globální adresa routeru. Místní uzly tento pˇríznak ignorují a z pole prefix si vezmou jen tu cˇ ást pˇredepsanou polem prefix length. Domácí agenti komunikující s mobilním uzlem, využijí pˇríznak k získání celé adresy routeru, ˚ které poté mohou použít, pokud mobilní uzel bude dynamicky vyhledávat domácí agenty. Poslední duležitá ˚ pole jsou valid lifetime (doba platnosti) a preferred lifetime (doba preferování). Valid lifetime pole urˇcuje platnost prefixu a pole preferred lifetime oznamuje, jak dlouho mají být preferovány adresy vzniklé z tohoto prefixu pomocí automatické konfigurace (obojí v sekundách). Pokud uplyne doba v preferred lifetime stává se daná adresa odmítanou. Sice je stále platnou, ale poˇcítaˇc by se jí mˇel vyhýbat a používat ji muže ˚ jen k pokraˇcování již probíhající komunikace. Po uplynutí doby v valid lifetime poli, se daná adresa stává neplatnou a poˇcítaˇc ji nesmí používat a mˇel by odstranit její pˇriˇrazení z odpovídajícího rozhraní. Poslední volby, které lze zaslat spolu s RA, jsou volby týkající se lokálních DNS serveru. ˚ Tˇemito jsou Recursive DNS Server (RDNSS, Rekurzivní DNS server) a DNS Search List (DNSSL, Prohledávací seznam DNS). Tyto volby mají stejný formát, který je vidˇet na obrázku A.8. Dlouho nebylo možné získat seznam lokálních DNS serveru˚ jinak než stavovˇe. Ale naštˇestí v roce 2010 vyšlo RFC 6106: IPv6 Router Advertisement Options for DNS Configuration, které umožnilo dostat volby o DNS serverech do bezstavové konfigurace. Zaˇcnu volbou Recursive DNS Server. Tato volba má v poli type hodnotu 25. Pole addresses of IPv6 Recursive DNS Servers (IPv6 adresy rekurzivních DNS serveru) ˚ obsahuje seznam lokálních DNS serveru. ˚ Poˇcet serveru˚ v seznamu muže ˚ být více. Pole lifetime oznamuje životnost pro všechny servery uvedené v seznamu. Tato volba se muže ˚ v RA objevit vícekrát s ruznými ˚ cˇ asy životnosti pro ruzné ˚ servery. Poˇcítaˇc si adresy DNS serveru˚ uloží lokálnˇe a servery kterým vypršel lifetime si vyˇradí. Pˇri novém pˇrijmutí RA si poˇcítaˇc aktualizuje lifetime u lokálnˇe uložených serveru˚ a nové servery v ohlášení si uloží. Je doporuˇceno, aby byl poˇcet serveru˚ uložených v poˇcítaˇci nastaven na hodnotu 3. Pokud je tento poˇcet pˇrekroˇcen poˇcítaˇc odstraní ty servery, 35
3. A NALÝZA IP V 6 KOMUNIKACE které mají nejnižší lifetime. Volba DNS Search List má type = 31. Pracuje se s ní shodnˇe jako s Recursive DNS Server. Akorát má místo addresses of IPv6 Recursive DNS Servers pole domain names of DNS Search List (Seznam prohledávaných pˇrípon). Rozdíl je, že v prvním pˇrípadˇe je to seznam IPv6 adres zatímco u DNS search list jsou v poli uložená doménová jména ve standardním tvaru. Použití tohoto seznamu je následovné. Pokud poˇcítaˇc neuspˇeje pˇri hledání informací k danému jménu a zadané jméno nekonˇcilo teˇckou, použije tento seznam k pˇripojování pˇrípon v nˇem obsažených. Potom hledá adresu pro dané vytvoˇrené jméno v DNS. RFC 6106 umožnuje ˇ pˇrijímat informace o DNS jak bezstavovˇe tak pomocí DHCPv6. Pokud jsou informace z obou typu˚ konfigurace relevantní, tak by je mˇel poˇcítaˇc kombinovat, aby v pˇrípadˇe problému s jedním mechanismem mˇel k dispozici jiný a mohl fungovat. 3.3.2 DHCPv6 DHCP (Dynamic Host Configuration Protocol) je celkem bˇežná záležitost i v IPv4, pomocí nˇej je poˇcítaˇc schopen získat všechny duležité ˚ údaje pro své fungování (IP adresu, masku podsítˇe, implicitní router i DNS server). [15] Dnešní operaˇcní systémy jsou zpravidla v základu nastaveny na provoz pomocí DHCP. V IPv6 prošel DHCP nˇekolika zmˇenami. Hlavní jsou zrušení broadcastových adres a poté schopnost všech uzlu˚ si nastavit local link address (napˇr. pomocí modified EUI-64, viz kapitola 3.3.1). A pˇrejmenoval se na DHCPv6 (Dynamic Host Configuration Protocol for IPv6). Na DHCPv6 se podílejí tˇri zaˇrízení. Klient, což je stroj, který chce získat údaje pro konfiguraci, DHCP server poskytující údaje a zprostˇredkovatel, který zajišt’uje styk mezi klientem a serverem. Server a zprostˇredkovatel potom bývají spoleˇcnˇe oznaˇcováni jako agenti. Že se v síti používá konfigurace pomocí DHCPv6, se klient dozví pomocí RA. (V RA bude nastaven pˇríznak M na hodnotu 1.) Každý úˇcastník DHCPv6 musí mít vygenerovaný DUID (DHCP Unique Identifier). DUID je unikátní identifikátor, který jednoznaˇcnˇe identifikuje každého úˇcastníka DHCPv6. Tento identifikátor by mˇel být stálý i v pˇrípadˇe výmˇeny sít’ové karty. Navíc každé rozhraní, které se konfiguruje pomocí DHCPv6, musí mít od klienta pˇridˇelen tzv. IA (identity association, identifikaˇcní asociace). IA by také mˇelo být nemˇenné. To znamená, že každý klient je jednoznaˇcnˇe identifikován a všechna rozhraní v rámci klienta jsou rozlišena pomocí IA. Pokud klient chce získat údaje ke konfiguraci, musí si vygenerovat IA a poté pošle DHCP zprávu solicit (výzvu) na adresu ff02::1:2 (všichni 36
3. A NALÝZA IP V 6 KOMUNIKACE DHCP agenti), kterou sdˇeluje, že shání DHCP server, který je ochoten mu pˇridˇelit adresu. Souˇcástí výzvy je i DUID a všechny IA spolu s vygenerovanou linkovou adresou. Pokud bude zpráva doruˇcena pˇrímo serveru, znamená to, že server a klient jsou na jedné lince a odpovˇed’ (advertise, ohlášení serveru) zašle pˇrímo na jeho domovskou adresu. Pokud výzva dojde zprostˇredkovateli, pˇrepošle ji na servery, které má uloženy v seznamu serveru. ˚ A následnˇe odpovˇed’ zašle zpˇet klientovi. V advertise je pˇribalena preference ukazující ochotu serveru poskytnout IP adresy danému klientovi. Klient si ze všech ohlášení, které mu dorazily, sestaví seznam DHCP serveru˚ a vybere si ten s nejvˇetší preferencí Když si klient vybral server, odešle zprávu request (žádost) stále ještˇe na obecnou adresu pro všechny agenty, protože o síti poˇrád nic neví. Soucˇ ástí žádosti je i DUID serveru (dorazil v advertise), který si vybral. Ostatní servery onu žádost ignorují a server, kterému je urˇcena zašle zpˇet klientovi reply (odpovˇed’) spolu s pˇridˇelenými adresami. Souˇcástí reply je trochu nepochopitelnˇe i jestli žádosti vyhovˇel, protože klient si ho vybral z kladných preferencí. Klient si následnˇe pomocí detekce duplicit ovˇerˇí pˇridˇelené adresy, a bud’ je odmítne nebo si je pˇridˇelí. Pˇridˇelené adresy nemají neomezenou platnost. Po jejím skonˇcení musí klient požádat o prodloužení nejdˇríve server, který mu adresy pˇridˇelil pomocí zprávy renew (obnovení). Pokud mu daný server neodpoví, pošle zprávu rebind (pˇrevázání) na adresu všech DHCP serveru. ˚ Touto zprávou zjišt’uje, zda není nˇejaký jiný server ochoten mu dané adresy prodloužit. Pokud klient konˇcí na síti, mˇel by požádat o uvolnˇení (release), aby mohla být jeho adresa pˇridˇelena dalšímu zájemci. Pokud se klient vrací zpˇet do sítˇe, tˇreba po neˇcekaném restartu, zjišt’uje, zda jsou jeho stávající sít’ové parametry v poˇrádku. V tomto pˇrípadˇe zašle na adresu všech agentu˚ zprávu confirm (potvrzení), jejíž souˇcásti jsou stávající parametry jeho IA. Pokud je vše v poˇrádku server potvrdí platnost, v opaˇcném pˇrípadˇe potvrzení zamítne. Server muže ˚ zaslat zprávu reconfigure. V této zprávˇe informuje o zmˇenˇe sít’ových parametru˚ a požaduje po klientovi, aby si nastavil nové parametry. Klient poté zašle zprávu renew a server mu následnˇe odpoví. Všechny zprávy mají stejný formát. Ten je vidˇet na obrázku 3.10. Zprávy se liší pouze v poli type. Ten definuje o jaký typ DHCP zprávy se jedná. Pole transaction-id (identifikátor transakce) slouží k pˇriˇrazení odpovˇedí k žádostem. Pole options obsahuje všechny informace, které jsou duležité ˚ pro konfiguraci. V DHCPv6 se lze více cˇ i ménˇe bránit proti podvržení DHCP serveru˚ nebo zmˇenám v DHCP zprávách. Za tímto úˇcelem byla vytvoˇrena volba authenication (autentizace). V pˇrípadˇe že klient chce ovˇerˇ it platnost zpráv, 37
3. A NALÝZA IP V 6 KOMUNIKACE 8 bits
0 bits
16 bits
Type
24 bits
32 bits
Transaction-id Options
Obrázek 3.10: Formát zpráv v DHCPv6 musí ji pˇribalit k úvodní výzvˇe spolu s metodami, které chce pro zabezpeˇcení používat a server následnˇe pˇripojí k advertise autentizaˇcní informace, které se stanou souˇcástí všech pozdˇejších vymˇenovaných ˇ zpráv. Bohužel je pro autentizaci použita symetrická kryptografie, a klíˇce použité pro autentizaci jsou uloženy na stranˇe serveru, což pˇredstavuje bezpeˇcnostní riziko pˇri napadení serveru. V praxi není autentizace v DHCPv6 moc použitelná. Lepší je to pˇri komunikaci mezi serverem a zprostˇredkovatelem, tam lze bez problému použít IPsec. V reálu to s DHCPv6 moc dobˇre nevypadá, duvodem ˚ jsou zaprvé identifikátory. Protože pokud je na stroji více operaˇcních systému nebo dojde k reinstalaci, tak poˇcítaˇc pokaždé bude vystupovat pod jiným DUID a v pˇrípadˇe klonování systému na více stroju˚ se bude zase více stroju˚ hlásit pod jedním DUID. Dalším duvodem ˚ je, že si správci rˇ ekli, že když mají k dispozici bezstavovou konfiguraci tak proˇc jí nepoužívat. Z tˇechto duvodu ˚ se moc pomocí DHCPv6 nekonfiguruje a ani se nepˇredpokládá, že by se to mˇelo v budoucnu zmˇenit. Bezstavová konfigurace umožnuje ˇ použití zjednodušené verze DHCPv6 (bezstavové DHCP). Do nedávna to bylo dokonce potˇreba, protože nešlo bezstavovou konfigurací získat adresy lokálních DNS serveru. ˚ Duvod ˚ pro použití bezstavového DHCP je, že bezstavovou konfigurací je možné získat pouze omezené množství informací. Pokud klient požaduje více informací, využije se k tomu bezstavové DHCP. Nastavení zasílání informací pomocí bezstavového DHCP je provedeno pomocí kombinace voleb RA (M=0 a O=1). Bezstavové DHCP má stejný formát zpráv jako klasické DHCP (obrázek 3.10), dokonce se s nimi stejnˇe pracuje. Bezstavové DHCP se snaží o maximální jednoduchost, proto na rozdíl od klasického DHCPv6 obsahuje pouze 4 typy zpráv request (žádost), reply (odpovˇed’), relay forward (pˇredání) a relay reply (odpovˇed’ k pˇredání). S tím, že relay forward a relay reply slouží ke stejnému úˇcelu jako request a reply, akorát se používají, pokud žádost dojde zprostˇredkovateli. Pokud chce klient získat informace bezstavovým DHCP odešle request, jehož souˇcástí jsou parametry, které požaduje. Server 38
3. A NALÝZA IP V 6 KOMUNIKACE podle toho sestaví reply a odešle ji zpˇet klientovi. Odpadá složité vymˇenoˇ vání zpráv, protože klient už má vˇetšinu nejduležitˇ ˚ ejších údaju˚ nastavenou bezstavovˇe.
3.4
Mobilita
Mobilita je všude proklamovaná novinka v protokolu IPv6. Zvláštˇe v dnešní dobˇe kdy má vˇetšina lidí notebook, smartphone a tito lidé jsou neustále na cestách. Ale pˇresto chtˇejí být neustále pˇripojení k Internetu, ve vlaku si chtˇejí vyˇrídit e-maily, atd. Fungování i v tˇechto pˇrípadech má zajistit mobilita. Pˇri vývoji protokolu IPv6 se s podporou mobilních zaˇrízení poˇcítalo již dlouho a proto je i fungování mobility celkem promyšlené. Základní myšlenkou fungování mobility je pˇredpoklad, že každé zaˇrízení je nˇekde doma. Domovem se v mobilitˇe myslí domácí sít’, kde má mobilní uzel zaregistrovanou domácí adresu. Jejím prostˇrednictvím by mˇel být stále k dispozici i v pˇrípadˇe, že se zrovna nenachází ve své domácí síti. Pˇri svých cestách by mˇel mobilní uzel dostávat tzv. doˇcasné adresy (care-of addresses). Mobilita zavedla další rozšiˇrující hlaviˇcku, jejíž formát je vidˇet na obrázku 3.11. Hlaviˇcka mobility se skládá z následujících polí. Payload protocol má stejnou funkci jako next header v ostatních hlaviˇckách. Za ní následuje header length, a za ní následuje pole MH Type. MH type urˇcuje jaká zpráva je poslána v této hlaviˇcce v poli message data. Dále je v hlaviˇcce pole reserved a checksum. Tato hlaviˇcka se používá, vždy když se pˇrenášejí zprávy pro konfiguraci mobility. Pˇrehled hlavních zpráv je uveden na obrázku A.9. Mobilita mimo jiné využívá mechanismy v Neighbor discovery a IPsecu. 8 bits
0 bits
Payload protocol
16 bits
Header length
24 bits
MH type
32 bits
Reserved
Checksum Message data
Obrázek 3.11: Formát hlaviˇcky mobilita
3.4.1 Pˇresun v síti Když se mobile node (MN, mobilní uzel) vydá na cesty a pˇripojí se k neznámé síti, musí poˇckat na pˇríchozí zprávu RA, podle kterého pozná, že 39
3. A NALÝZA IP V 6 KOMUNIKACE se nalézá v jiné síti, než je jeho domácí. Aby mohl mobilní uzel v cizí síti normálnˇe fungovat, musí si vygenerovat local link address. Podle informací obsažené v RA si MN nastaví pomocí bezstavové konfigurace nebo pomocí DHCPv6, prefix sítˇe, adresy lokálních DNS serveru˚ a dalších parametru. ˚ Z RA se dozví i adresy potenciálních implicitních routeru˚ a jeden si zvolí za svuj. ˚ Jeden z nabízených prefixu˚ si zvolí za svuj ˚ primární, aby ho mohl použít k vytvoˇrení primární doˇcasné adresy, kterou zaregistruje u domácího agenta. 3.4.2 Získání domácího agenta Registrace domácího agenta (home agent, HA) zaˇcíná zjištˇením adres routeru˚ v domácí síti, kteˇrí jsou ochotni sloužit MN jako domácí agent. Pro zjištˇení adres potenciálních agentu˚ zašle MN ICMP zprávu Home Agent Address Discovery Request Message (žádost o adresy domácích agentu) ˚ do domácí sítˇe. Formát zprávy je vidˇet na obrázku 3.12. Jako data nese pouze identifikátor, aby bylo možné pˇriˇradit následující odpovˇed’ ke správné žádosti. Tuto zprávu odešle mobilní uzel na anycastovou adresu která má tvar prefix_ podsite:fdff:ffff:ffff:fffe a uskupuje všechny domácí agenty v síti. Po pˇríchodu zprávy zjistí domácí agent, kterému zpráva došla, adresy všech potenciálních agentu˚ spolu s preferencí poskytnout mobilnímu uzlu své služby jako domácí agent. 8 bits
0 bits
Type = 144
16 bits
Code = 0 Identifier
24 bits
32 bits
Checksum Reserved = 0
Obrázek 3.12: Formát zprávy Home Agent Address Discovery Request Message Tyto adresy seˇradí implicitní router v domácí síti podle preference a vytvoˇrí z nich seznam adres v ICMP zprávˇe Home Agent Address Discovery Reply Message, obrázek 3.13. Router následnˇe zašle mobilnímu uzlu na jeho primární adresu tento seznam, ze kterého by si mˇel MN vybrat svého HA. Jakmile si MN vybere, zašle zvolenému HA zprávu binding update (aktualizace vazby). Její formát je vidˇet na obrázku 3.14. Binding update se skládá z následujících polí. Sequence# (poˇradové cˇ íslo), lifetime (životnost) a cˇ tveˇrice pˇríznaku˚ tvoˇrí základ zprávy binding update. Za nimi následuje pole pro volby. Sequence# urˇcuje kolikátá je to zpráva binding 40
3. A NALÝZA IP V 6 KOMUNIKACE 8 bits
0 bits
Type = 145
16 bits
Code = 0
24 bits
32 bits
Checksum Reserved = 0
Identifier Home Agent Addresses
Obrázek 3.13: Formát zprávy Home Agent Address Discovery Reply Message 8 bits
0 bits
16 bits
24 bits
32 bits
Sequence # A H L K
Reserved = 0
Lifetime Mobility Options
Obrázek 3.14: Formát zprávy binding update (aktualizace vazby) update odeslaná danému uzlu a životnost urˇcuje platnost doˇcasné adresy. ˇ Ctveˇ rice pˇríznaku˚ je „A“, „H“, „L“, „K“. Pˇríznak „A“ (acknowledge) oznamuje, že odesílající uzel si žádá zaslání odpovˇedi na binding update v podobˇe zprávy binding acknowledgement (potvrzení vazby). V tuto dobu je nejduležitˇ ˚ ejší pˇríznak „H“ (home registration), který lze použít pouze pˇri zaslání této zprávy routeru v domácí síti a znamená, že po nˇem žádá, aby se stal jeho HA. Tˇretí je pˇríznak „L“, pomocí kterého uzel oznamuje HA, aby se staral i o jeho lokální adresu. Tento pˇríznak lze použít pouze tehdy, pokud má jeho domácí adresa stejné interface ID jako jeho lokální. Poslední pˇríznak „K“ oznamuje domácímu agentovi, že mobilní uzel podporuje protokol IKEv2 v IPsecu. Do pole options je možné pˇridat doplnující ˇ volby. V tuto chvíli mobilní uzel vytvoˇrí ESP tunel 7 mezi ním a vybraným domácím agentem a veškerá další komunikace s domácí sítí bude probíhat pˇres HA skrze právˇe vytvoˇrený ESP tunel. [4] Vˇcetnˇe komunikace pouze mezi HA a MN. MN nastaví povinnˇe pˇríznak „H“ na hodnotu 1 a odešle zprávu tunelem zpˇet pˇrímo na adresu zvoleného HA. Pokud je vše v poˇrádku tak domácí agent zkontroluje pomocí detekce 7. Nebudu zde popisovat jak se ustavuje ESP tunel, ale mohu pro tuto problematiku doporuˇcit bakaláˇrskou práci zabývající se IPsecem. K dispozici zde: http://is.muni.cz/th/ 325290/fi_b/
41
3. A NALÝZA IP V 6 KOMUNIKACE duplicit (odešle NS na domácí adresu MN) Pokud mu nepˇrijde žádná odpovˇed’, znamená to, že domácí adresu uzlu nikdo jiný nepoužívá. Dále si HA uloží doˇcasnou adresu do datových struktur. Zašle MN kladnou zprávu binding acknowledgement, obrázek 3.15. Kladná odpovˇed’ se urˇcuje podle pole status (stav), pokud obsahuje hodnotu 0. Od této chvíle funguje pro mobilní uzel jako domácí agent. Ještˇe zbývá nechat na sebe pˇresmˇerovat komunikaci v lokální síti. Zašle proto po síti nˇekolik zpráv NA, v nichž je uvedena jak domácí adresa MN, tak i jeho lokální adresa a uzly v síti budou zprávy urˇcené MN odesílat na adresu HA. To samé by udˇelal i s lokální adresou MN pokud by byl nastaven pˇríznak L na 1. 0 bits
8 bits
16 bits
Sequence #
32 bits
24 bits
Status
K
Reserved = 0
Lifetime Mobility options
Obrázek 3.15: Formát zprávy Binding acknowledgement (Potvrzení vazby)
3.4.3 Optimalizace cesty Pokud se objeví poˇcítaˇc, který chce s mobilním uzlem komunikovat, ale neví o tom, že se uzel nenalézá v domácí síti, tak nic neˇreší a data odešle klasicky na domácí adresu mobilního uzlu. Domácí agent tyto data pˇrijme, zabalí je do nového datagramu a tunelem je pˇrepošle mobilnímu uzlu. Ten v tuto chvíli ví, že korespondent (poˇcítaˇc, se kterým komunikuje) netuší o jeho mobilitˇe. Ted’ by klidnˇe mohl mobilní uzel odpovˇedˇet stylem, že si nepˇreje, aby korespondent vˇedˇel, že se nalézá mimo domácí sít’. A odpovˇed’ by zaslal domácímu agentovi, který by ji dále pˇreposlal korespondentovi. Takhle by mohly oba uzly vesele komunikovat dál. Ovšem to by znamenalo zbyteˇcnou zátˇež pro sít’ a domácího agenta. Právˇe v tuto chvíli pˇrichází na rˇ adu optimalizace cesty. Proto místo, aby mobilní uzel poslal odpovˇed’ korespondentovi pˇres HA, bude ho informovat o jeho novém umístˇení. Samozˇrejmˇe je nutné, aby se vuˇ ˚ ci korespondentovi prokázal, že je skuteˇcnˇe tím, za koho se vydává. Zašle dva na sobˇe nezávislé datagramy home test init (HoTI, záhajení testu domácí adresy) a care-of test init (CoTI, zahájení testu doˇcasné adresy). Tyto zprávy jsou pˇrenášeny v hlaviˇcce mobility v poli message data. HoTI zašle pˇres 42
3. A NALÝZA IP V 6 KOMUNIKACE tunel domácímu agentovi, který jej pˇrepošle korespondentovi. A CoTI zašle korespondentovi pˇrímo. Formát zpráv je podobný a je vidˇet na obrázku 3.16. Jedinou informaci ve zprávách je hodnota cookie, která je pro obˇe hlaviˇcky náhodnˇe vygenerovaná. 0 bits
8 bits
16 bits
24 bits
32 bits
Reserved = 0 Home / Care-of Init Cookie
Mobility options
Obrázek 3.16: Home Test Init a Care-of Test Init zprávy Korespondent reaguje na obˇe zprávy vytvoˇrením nových hodnot tokenu˚ pro každou test init zprávu. [5] Pro HoTI vytvoˇrí home keygen token a pro CoTI care-of keygen token. Pro vypoˇcítání tokenu˚ použije korespondent svuj ˚ interní klíˇc (Kcn), hodnoty nonce, které si generuje v nˇekolikaminutových intervalech. Jelikož HoTI a CoTI cestují jinudy, muže ˚ se stát, že hodnoty budou rozdílné. Dále obˇe adresy mobilního uzlu (tedy jak doˇcasnou tak domácí) a pˇridá k nim ještˇe hodnotu 0 pro home keygen token a 1 pro care-of keygen token. A vše to pˇredhodí hashovací funkci HMAC_SHA1. Vzorec pro výpoˇcet tokenu˚ je následující: home keygen token :=First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))), respektive care-of keygen token :=First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))). Kde znak „|”(pipe, roura) znaˇcí zˇretˇezení. Z tohoto výsledku se vezme prvních 64 bitu, ˚ které tvoˇrí jednotlivé tokeny. Korespondent následnˇe vytvoˇrí odpovˇedi na HoTI a CoTI. Do tˇechto odpovˇedí vloží hodnotu nonce, použité cookie a tokeny. Tyto odpovˇedi jsou pojmenovány home test (HoT, test domácí adresy) a care-of test (CoT, test doˇcasné adresy). Formát zpráv je vidˇet na obrázku 3.17. HoT odešle na domácí adresu MN a CoT na doˇcasnou adresu MN. Když dorazí HoT a CoT zprávy, vytvoˇrí mobilní uzel pomocí tokenu˚ klíˇc (Kbm) pro binding update podle následujícího vzorce:
43
3. A NALÝZA IP V 6 KOMUNIKACE 8 bits
0 bits
16 bits
24 bits
32 bits
Home / Care-of Nonce Index Home / Care-of Init Cookie
Home / Care-of Keygen Token
Mobility options
Obrázek 3.17: Home Test a Care-of Test zprávy Kbm = SHA-1 (home keygen token | care-of keygen token). A pomocí nˇej, doˇcasné adresy a adresy korespondenta, spoˇcítá obdobnˇe authenticator (autentizaˇcní hodnotu), která bude souˇcástí volby binding authorization data (autorizaˇcní data 8 ) v binding update. Dále pˇridá volbu nonce indices obsahující indexy nonce hodnot. Formát obou voleb je na obrázku A.10, resp. A.11. Tento binding update zasílá MN pˇrímo na adresu korespondenta. Ten si ve své pamˇeti najde hodnoty nonce podle zaslaných indexu. ˚ A stejným zpusobem ˚ provede znovu výpoˇcet autentizaˇcních dat. Výsledek porovná s tím, co mu dorazilo. Pokud se hodnoty shodují, ví, že jedná skuteˇcnˇe s tím, komu poslal puvodní ˚ data. 3.4.4 Pˇrenos dat Poté co se trochu složitˇe zajistí, že korespondent muže ˚ komunikovat pˇrímo s MH, už skoro nic nebrání jednoduchému zasílání dat. Zaˇcal bych s posláním dat od korespondenta. Každý uzel by si mˇel udržovat cache vazeb. V nˇem se nachází seznam MN, se kterými korespondent komunikuje. Cache vazeb by mˇela obsahovat domácí adresu MN, podle které se v cache vyhledává, odpovídající doˇcasnou adresu, dobu životnosti doˇcasné adresy ze zprávy binding update (po jejímž uplynutí se stává doˇcasná adresa neplatnou a musí být odstranˇena), dále pˇríznak zda pro mobilní uzel nevykonává funkci HA (to platí jen pro routery) a souˇcasnou nejvyšší hodnotu ze sequence# z binding update. 8. Nejedná se o pˇreklep, ale skuteˇcnˇe se autentizaˇcní hodnota pˇrenáší v autorizaˇcní volbˇe, i když autorizace a autentizace jsou dva odlišné termíny
44
3. A NALÝZA IP V 6 KOMUNIKACE Pokaždé, když chce korespondent poslat nˇejaká data, mˇel by se kouknout do cache vazeb, zdali se v ní nevyskytuje záznam k adrese, kam chce data poslat. Pokud záznam existuje, pˇridá do datagramu hlaviˇcku smˇerování typu 2 a odešle data na doˇcasnou adresu MN. Do hlaviˇcky smˇerování pˇridá jedinou adresu a to domácí adresu MN. Hlaviˇcka smˇerování typu 2 vychází z klasické hlaviˇcky smˇerování typu 0. Ale obsahuje pouze jedinou adresu a to domácí adresu MN. Tento typ hlaviˇcky byl definován pˇrímo pro mobilitu. Její formát je vidˇet na obrázku 3.18. Když data dorazí k mobilnímu uzlu, zpracuje hlaviˇcku smˇerování standardním zpusobem ˚ a odešle data na domácí adresu. 8 bits
0 bits
16 bits
Header length = 2
Next header
24 bits
Routing type = 2
32 bits
Segments left = 1
Reserved = 0
Home Address
Obrázek 3.18: Hlaviˇcka smˇerování typu 2 Pokud bude data odesílat mobilní uzel, pˇridá povinnˇe hlaviˇcku Destination options, ve které uvede svou domácí adresu. Korespondent musí následnˇe vzít domácí adresu a zkopírovat ji na místo odesílatele datagramu, tím se zajistí, že se transportní vrstva a vyšší vrstvy o mobilitˇe nedovˇedí a vše bude mít stále ve své režii sít’ová vrstva.
3.4.5 Návrat domu˚ Když se mobilní uzel vrátí zpˇet do své domácí sítˇe, nemá zatím ponˇetí, že je zpˇet. To že se mobilní uzel ocitl ve své domovské síti, se dozví stejnˇe jako v jakékoliv jiné síti a to pomocí RA. V tuto chvíli zašle zprávu binding update domácímu agentovi, ovšem s polem lifetime nastaven na nulu. Tím se domácí agent dozví, že má vazbu odstranit z cache vazeb, kde mˇel uloženou doˇcasnou adresu mobilního uzlu. U domácího agenta je nutné nastavit pˇríznak H na hodnotu 1. Ostatním uzlum, ˚ které má také v cache vazeb zašle rovnˇež stejnou zprávu binding update, ovšem už bez nastaveného pˇríznaku H. Na závˇer se mobilní uzel musí chopit všech svých závazku˚ a odešle po síti nˇekolik NA, cˇ ímž vyruší neighbor advertisement rozeslané ted’ už bývalým domácím agentem. 45
3. A NALÝZA IP V 6 KOMUNIKACE
3.5
Bezpeˇcnost IPv6
Bezpeˇcnost v IPv6 je zajištˇena pomocí IPsecu. IPsec je rozšíˇrení IP protokolu zajišt’ující jeho bezpeˇcnost a bezpeˇcnost protokolum ˚ na vyšších vrstvách. Základem IPsecu jsou dvˇe hlaviˇcky Authentication header (AH) obrázek 3.19 a ESP header obrázek 3.20. Authentication header zajišt’uje ovˇerˇ ení pravosti datagramu pˇredevším adres v nˇem obsažených a obsahu. ESP zajišt’uje kromˇe funkcí obsažených v AH navíc zašifrování obsahu. Protože ESP nabízí více funkcí, jak zabezpeˇcit data, zaˇcíná se od AH ustupovat a používá se pˇrevážnˇe jen ESP. Pˇredpokládá se, že se v budoucnu pˇrestane kompletnˇe používat AH a zustane ˚ se jen u ESP. 8 bits
0 bits
Next header
16 bits
24 bits
Payload length
32 bits
Reserved
Security parameters index (SPI) Sequence number
Authentication data
Obrázek 3.19: Formát Authentication header 0 bits
8 bits
16 bits
24 bits
32 bits
Security parameters index (SPI) Sequence number
Payload data Padding Pad length
Next header
Authentication data
Obrázek 3.20: Formát ESP header Hlaviˇcky IPsecu fungují ve dvou režimech, v tunelovacím a transportním. Transportní režim funguje zpusobem, ˚ že hlaviˇcka IPsecu je pˇridána do datagramu a takto odeslána. Tunelovací režim obalí celý stávající datagram 46
3. A NALÝZA IP V 6 KOMUNIKACE do nového datagramu vˇcetnˇe pˇridání nových hlaviˇcek vˇcetnˇe tˇech z IPsecu [21]. Tunelovací režim poskytuje tedy vˇetší úrovenˇ zabezpeˇcení než transportní režim, protože ten odesílá cˇ ást puvodního ˚ datagramu v nezašifrované podobˇe. Útoˇcník sice nezíská žádná data, ale bude mít pˇrístup k adresám v datagramu a bude moci analyzovat charakter jejich komunikace. Pˇred použitím IPsecu je nutné, aby obˇe strany komunikace sdílely potˇrebné informace jako napˇr. konkrétní šifrovací a hashovací algoritmy, hodnoty klíˇcu, ˚ cˇ ítaˇce, dobu životnosti a další. Všechny tyto hodnoty tvoˇrí security association (SA, bezpeˇcnostní asociaci). SA je nutné pˇri navazování komunikace, protože SA spravuje parametry pro použití IPsecu s kterými musí obˇe strany souhlasit, aby mohla komunikace probíhat v zabezpeˇcené podobˇe. IPsec se nepoužívá pouze pˇri komunikaci mezi dvˇema koncovými uzly, ale dá se použít i v DHCPv6 na výmˇenu zpráv mezi zprostˇredkovateli a DHCP serverem. Bohužel nejde IPsec použít pro komunikaci mezi agenty (oznaˇcení pro DHCP server a zprostˇredkovatele) a klientem v DHCPv6. Tam se používá HMAC protokol a MD5 a vše je postaveno na symetrické kryptografii. Další pˇrípad, kdy se používá IPsec, respektive pouze ESP tunelovací režim, je v pˇrípadˇe mobility. V mobilitˇe pˇres ESP tunel probíhá komunikace mezi domácím agentem a mobilním uzlem. Neighbor discovery umožnuje ˇ také pracovat v bezpeˇcném režimu tzv. SEND (SEcure Neighbor Disvovery). Puvodní ˚ návrh SENDu poˇcítal také s využitím IPsecu, ale protože pˇri nˇem dochází k velké režii, byl tento zpusob ˚ zavrhnut. Nyní se pro SEND používají Cryptographically Generated Addresses (CGA, Kryptograficky generované adresy).
47
4 Výukové animace protokolu IPv6 V této kapitole se zabývám Výukovými animacemi, které vznikly v rámci této práce, vˇcetnˇe jejich ovládání. Popisuji zde také duvody ˚ vzniku tˇechto animací, spolu se srovnáním s dosud vytvoˇrenými animacemi na podobné téma. Dále zde zminuji ˇ nástroj Adobe Flash Professional CS5, ve kterém jsem tyto animace vytváˇrel, zárovenˇ s krátkým popisem tohoto programu.
4.1
Duvody ˚ pro animaci
Pˇrestože je IPv6 v poslední dobˇe hodnˇe probírané téma, pˇrekvapilo mˇe, že se nikde na Internetu nenachází žádné animace popisující mechanismy v IPv6. Je sice možné najít na Internetu cˇ lánky zabývající se právˇe IPv6 nebo tištˇené publikace, ale nikde nelze najít žádné ucelené animace, které by ukázaly, jak fungují mechanismy IPv61 . Jediné animace zabývající se IPv6 jsou bud’ prezentace vytvoˇrené v programu Microsoft PowerPoint nebo videa obsahující akorát popis IPv6. Podarˇ ilo se mi sice najít jednu animaci se jménem What is IPv62 , ale ta bohužel popisuje jen vlastnosti IPv6. Což jsem nepovažoval jako relevantní zdroj a rozhodl jsem se vytvoˇrit výukové animace, kde je názornˇe pˇredvedeno, jak mechanismy v IPv6 fungují. A to stylem snadným pro pochopení studentum ˚ zabývajících se sítˇemi i lidem kteˇrí toho o sítích tolik neví. I když na fakultˇe existuje rˇ ada pˇredmˇetu, ˚ ve kterých se IPv6 probírá, stále existuje spousta studentu, ˚ kteˇrí na konci kurzu nepochopí, jak fungují jednotlivé mechanismy protokolu IPv6. Což byl další duvod ˚ pro jejich vytvoˇrení.
4.2
Adobe Flash Professional
Pro tvorbu animací byl použit nástroj Adobe Flash Professional CS5. Flash je vektorový grafický program používaný hlavnˇe na vytváˇrení interaktivních webových prezentací, animací a her. Jedním z duvod ˚ u, ˚ proˇc byl pro tvorbu výukových animací zvolen právˇe tento nástroj, je relativnˇe snadná práce v samotném programu, jehož prostˇredí je rozdˇeleno do nˇekolika cˇ ástí. Nejvˇetší plochu v programu zaujímá pracovní plocha, na kterou se umíst’ují objekty, které jsou poté zobrazeny ve výsledné animaci. [3] Pracovní 1. Jedny pˇreci jen existují, ty vytvoˇril minulý rok jiný student z fakulty a zabývají se IPsecem 2. http://www.explania.com/en/channels/technology/detail/ what-is-ipv6
48
4. V ÝUKOVÉ ANIMACE PROTOKOLU IP V 6 plocha je tou nejduležitˇ ˚ ejší cˇ ástí v programu. Druhou cˇ ást zabírá cˇ asová osa, která usnadnuje ˇ tvorbu animací a na které jsou všechny prvky použité v animacích pˇrehlednˇe rozmístˇené ve vrstvách. Zárovenˇ cˇ asová osa urˇcuje, jak dlouho bude výsledná animace trvat a je na ní zobrazeno, v jaké cˇ ásti projekce se ten který objekt nachází a jak dlouho bude trvat jeho animovaný pohyb. Poslední cˇ ást v programu tvoˇrí ruzné ˚ nástroje a funkce, které se dají pˇri vytváˇrení projektu˚ využít. Ne vše lze v programu Adobe Flash udˇelat jen pomocí umístˇení objektu, ˚ nˇekdy je nutné nˇeco naprogramovat. K tomu se používá scriptovací jazyk Actionscript, vyvíjený firmou Adobe. Pomocí nˇej je možné nechat vykonat objekty složitˇejší funkce. Kromˇe toho má Flash velmi dobrou podporu ve vˇetšinˇe operaˇcních systému˚ a internetových prohlížeˇcu˚ a jeho neustálý vývoj znamená, že vývojáˇri pˇridávají stále nové funkce, a vylepšují podporu napˇríˇc hardwarem a softwarem 3 . Právˇe tato podpora byla dalším duvodem ˚ výbˇeru programu Adobe Flash pro praktickou cˇ ást práce, jelikož se výsledné animace umístí na web, kde k nim budou mít uživatelé volný pˇrístup.
4.3
Ovládání animací
Ovládání animací je snadné a intuitivní. Základní funkce pro ovládání animace jsou následující. Primární funkce jsou play (pˇrehrávání), fast play (rychlé pˇrehrávání vpˇred), fast back-play (rychlé pˇrehrávání zpˇet). Dále jsou to funkce pro skoky v animacích. jump back a jump forward (skok zpˇet a vpˇred). Poslední funkce, kterou animace používají, je repeat, která je k dispozici až na konci animace a vrací jednotlivé animace zpˇet na zaˇcátek. Všechny tyto funkce lze používat pomocí kurzoru a stejnˇe pojmenovaných tlaˇcítek v levém dolním a horním rohu. Tlaˇcítka byla použita s ohledem na podobnost vzhledu s pˇrehrávaˇci, aby bylo na první pohled zˇrejmé, k cˇ emu má dané tlaˇcítko sloužit. Zárovenˇ je každé tlaˇcítko opatˇreno textem popisující jeho funkci. Tento text se zobrazí pˇri najetí kurzoru nad dané tlaˇcítko. Ovládat animace lze i pomocí klávesnice. Základní funkce play, se používá pomocí tlaˇcítek SPACE a PAGE DOWN. Pro rychlá pˇrehrávání se používají klávesy M a N. M slouží pro zrychlené pˇrehrávání vpˇred a klávesa N pro zpˇet. Funkce jump forward lze použít stiskem klávesy RIGHT ARROW. A pro ovládání funkce jump back je rˇ ešena pomocí kláves LEFT ARROW a PAGE UP. Poslední funkce, kterou lze ovládat pomocí klávesnice je funkce repeat. Pro tuto funkci je použito tlaˇcítko HOME. 3. Od verze 10.2 podporuje hardwarovou akceleraci pˇrehrávání videa.
49
4. V ÝUKOVÉ ANIMACE PROTOKOLU IP V 6 Duvod, ˚ proˇc není na funkci menu pˇridˇelena žádná klávesa, je ten, že v menu se lze pohybovat pouze pomocí myši proto by nebylo úˇcelné použít klávesu, pro pˇrechod do menu, když poté by uživatel musel stejnˇe použít myš. Vedle tlaˇcítka menu se nachází tlaˇcítko obsahující odkazy na relevantní stránky zabývající se danou problematikou. Šedá tlaˇcítka v menu pˇresmˇerovávají na animace konkrétních mechanismu. ˚ Dále se v menu nalézá ještˇe jedno tlaˇcítko. Toto tlaˇcítko s otazníkem slouží k zobrazení nápovˇedy, kde je shrnuto ovládání animací. Pro pohyb v nˇekterých animacích slouží i cˇ asová osa umístˇená dole. Ta znázornuje, ˇ v jakém úseku animace se uživatel právˇe nachází, a šedé šipky se dají použít pro pˇrechod na zaˇcátek dílˇcích bloku˚ animace. Takové ovládání animací bylo použito s ohledem na jeho pˇrehlednost a intuitivnost. Zárovenˇ bylo navrženo tak, aby šlo používat i s prezentérem používaným vyuˇcujícími na fakultˇe informatiky. Z toho duvodu ˚ mají nˇekteré funkce více možností ovládání pˇres klávesnici (PAGE UP a PAGE DOWN), nebot’ tyto prezentéry simulují právˇe jejich stisk.
4.4
Vytvoˇrené animace
Zde bych rád popsal jednotlivé animace. První animace je datagrams. V této animaci je zobrazeno, jak probíhá zˇretˇezení hlaviˇcek protokolu IPv6. Protokol IPv6 se snažil zjednodušit hlaviˇcky zavedením rozšiˇrujících hlaviˇcek. Tím bylo zajištˇeno, že se použijí pouze hlaviˇcky, které jsou relevantní. IPv4 totiž umist’oval skoro všechny informace do základní hlaviˇcky vˇcetnˇe funkcí, které se nemusely pˇri pˇrenosu datagramu použít, napˇríklad fragmentace. Tato animace má jiný styl ovládání než ostatní animace. V této animaci slouží šedá tlaˇcítka na pravé stranˇe k výbˇeru hlaviˇcek použitých k zˇretˇezení. Aktuální zˇretˇezení je poté zobrazeno dole pomocí cˇ tvercových tlaˇcítek. Pomocí nich lze vybírat jaká hlaviˇcka má být zobrazena. Pole v hlaviˇckách obsahují další doplnkové ˇ informace, které se zobrazují pˇri najetí nad nˇe. Další animace se zabývají typy adresování (unicast, multicast a anycast). V tˇechto animacích je vidˇet jakým stylem probíhá komunikace pomocí jednotlivých typu. ˚ Dále se v každé animaci nachází formát jejich adres. V unicastu a multicastu lze kliknout na jednotlivé pole v adrese a poté se vypíší informace k danému poli. V multicastu se na levé stranˇe nachází radio-buttony. Pomocí nich lze nastavit druh multicastu, který se následnˇe projeví na zmˇenˇe group identifier. Pohyb v tˇechto animacích je rˇ ešen hlavnˇe pomocí tlaˇcítek a kláves RIGHT 50
4. V ÝUKOVÉ ANIMACE PROTOKOLU IP V 6 a LEFT ARROW. Následnˇe je možné mezi touto skupinou animací pˇrecházet pomocí tlaˇcítek umístˇených na pravé stranˇe. Ve tˇretí skupinˇe jsem se zabýval fungováním protokolu neighbor discovery. Pˇresnˇeji Zjišt’ování linkových adres a Detekci dosažitelnosti souseda. V tˇechto animacích je názornˇe ukázán formát zpráv používaných v neighbor discovery a jakým zpusoben ˚ probíhá komunikace mezi úˇcastníky. Ovládání v tˇechto animacích je standardní, jak bylo popsáno v pˇredchozí kapitole. Za zmínku stojí ještˇe animace neighbor unreachability detection, kde pˇri najetí myší nad jednotlivé stavy se zobrazí popis stavu a co mu pˇredchází, respektive následuje po nˇem. ˇ Ctvrtá cˇ ást popisuje fungování bezstavové autokonfigurace. Na zaˇcátku animace je zobrazeno, jak si uzel vygeneruje lokální adresu. Dále je v animaci zobrazeno, jakým zpusobem ˚ dochází k výmˇenˇe zpráv nutných pro správné konfigurování pˇripojení vˇcetnˇe jejich formátu a použitých voleb. Tato animace se ovládá standardním zpusobem. ˚ Poslední animace je Mobilita. Tato animace názornˇe pˇredvádí, jak probíhá získání domácího agenta, optimalizaci cesty pro komunikaci s uzlem, který je pˇripojen nˇekde v Internetu. Dále je v animaci vidˇet jak probíhá komunikace po optimalizaci cesty a návrat mobilního uzlu zpˇet do domácí sítˇe. Také tato animace obsahuje klasické ovládání popsané dˇríve. V menu je ještˇe uveden odkaz na animace IPsec, které vytvoˇril jiný student. Nicménˇe dohodl jsem se, že by bylo vhodnˇe mít je zde uvedeny, jelikož se také zabývají mechanismem IPv6.
51
5 Závˇer Cílem práce bylo vytvoˇrit výukové animace vybraných mechanismu˚ používaných v protokolu IPv6, které mˇely vhodným zpusobem ˚ prezentovat, jak dané mechanismy pracují. V písemné práci jsem je mˇel podrobnˇe popsat. Animace vytvoˇrené pro praktickou cˇ ást najdou využití hlavnˇe ve výuce sít’ových pˇredmˇetu˚ na fakultˇe informatiky, které mají souˇcástí osnovy i protokol IPv6. Výsledné animace jsem pˇredložil nˇekolika studentum ˚ z fakulty, aby se mi k nim pozdˇeji vyjádˇrili a sdˇelili mi své dojmy. Zejména jestli byli schopni pochopit, jak dané mechanismy fungují, zda jim pˇrijde ovládání intuitivní a také, jaký mají z animací celkový dojem. Vzorek studentu˚ obsahoval, jak studenty kteˇrí prošli vˇetším množstvím sít’ových pˇredmˇetu, ˚ tak i tˇech, kteˇrí mají za sebou jen základní pˇredmˇet týkající se sítí. Na základˇe tˇechto podnˇetu˚ získaly animace souˇcasnou podobu. Osobnˇe vˇerˇ ím, že tyto animace budou používat i uživatelé, kteˇrí nejsou z fakulty informatiky. Textová cˇ ást práce má sloužit jako doplnkový ˇ a rozšiˇrující materiál k vytvoˇreným animacím. V této cˇ ásti jsem se snažil o detailní popis fungování vybraných mechanismu, ˚ doplnˇené pro názornost formáty zpráv, použitých pro výmˇenu informací. Jelikož mechanismy obsahují vˇetší množství informací, které nemohou být opomenuty, je rozsah textové cˇ ásti vˇetší než je u bakaláˇrských prací obvyklé. Tato práce mi ukázala, že má smysl vytvoˇrit i animace na další mechanismy IPv6, nebot’ studentum ˚ je názornˇe a nenásilnou cestou pˇredvedeno, jak dané mechanismy fungují. Ve výsledku to muže ˚ znamenat, že si z animací zapamatují více, než kdyby cˇ etli jen holý text. Dále tato práce nabízí možnost budoucího rozšíˇrení o další animace v podobném duchu jako s IPsecem. Kdy je možné tyto animace provázat, pˇrípadnˇe jim dát v budoucnu jednotnou podobu.
52
Literatura [1] 6DEPLOY. IPv6 Autoconfiguration [online]. [cit. 27. bˇrezna 2012]. Dostupné z:
[2] ABLEY, J., NEVILLE-NEIL, G., SAVOLA, P. Deprecation of Type 0 Routing Headers in IPv6. [online]. prosinec 2007. [cit. 13. bˇrezna 2012]. Dostupné z: [3] Adobe Creative Team. Adobe Flash CS5 Professional, Oficiální výukový kurz. 1. vyd. Brno: COMPUTER PRESS, 2010. 392 s.: ISBN: 978-80-2513224-1. [cit. 13. kvˇetna 2012]. [4] ARKKO, Jari, DEVARAPALLI, Vijay, DUPONT, Francis. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. [online]. cˇ erven 2004 [cit. 9. kvˇetna 2012]. Dostupné z: [5] ARKKO, Jari, JOHNSON, David B., PERKINS, Charles E. Mobility Support in IPv6. [online]. cˇ ervenec 2011 [cit. 9. kvˇetna 2012]. Dostupné z: [6] BÉLAI, I. Referenˇcný model komunikácie ISO/OSI [online]. 2011 [cit. 21. listopadu 2011]. Slovenská technická univerzita v Bratislavˇe, Fakulta elektrotechniky a informatiky. Dostupné z: [7] BIONDI, Philippe, EBALARD, Arnaud. IPv6 Routing Header Security s. 57. [online]. 2007. [cit. 13. bˇrezna 2012]. Dostupné z: [8] DEERING, Stephen E., HINDEN, Robert M. Internet Protocol, Version 6 (IPv6) Specification. [online]. prosinec 1998 [cit. 4. dubna 2012]. Dostupné z: [9] HABERMAN, Brian, THALER, Dave. Unicast-Prefix-based IPv6 Multicast Addresses. [online]. srpen 2002 [cit. 5. ledna 2012]. Dostupné z: [10] HABERMAN, Brian, SAVOLA, Pekka. Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. [online]. listopad 2004 53
ˇ 5. Z ÁV ER
[cit. 5. ledna 2012]. Dostupné z: [11] HABERMAN, Brian, HINDEN, Robert M. Unique Local IPv6 Unicast Addresses. [online]. rˇ íjen 2005 [cit. 2. ledna 2012]. Dostupné z: [12] HAGEN, Silvia. IPv6 essentials. 2nd ed. Beijing: O´Reilly, 2006, 418 s. ISBN 05-961-0058-2. [cit. 15. záˇrí 2011] [13] HUSTON, Geoff. IPv6 s. 35. [online]. 2012 [cit. 12. bˇrezna 2012]. Dostupné z: [14] KAWAMURA, Seiichi, KAWASHIMA, Masanobu. A Recommendation for IPv6 Address Text Representation. [online]. srpen 2010 [cit. 25. února 2012]. Dostupné z: [15] KERR, Shane. DHCPv6. rˇ íjen 2006 [cit. 22. bˇrezna 2012]. Dostupné z: [16] NARTEN Thomas , NORDMARK, Erik, SIMPSON, William Allen , SOLIMAN, Hesman. Neighbor Discovery for IP version 6 (IPv6). [online]. záˇrí 2007 [cit. 25. bˇrezna 2012]. Dostupné z: [17] NARTEN Thomas , THOMSON, Susan, JINMEI, Tatuya. IPv6 Stateless Address Autoconfiguration. [online]. záˇrí 2007 [cit. 27. bˇrezna 2012]. Dostupné z: [18] PETERKA, Jiˇrí. Referenˇcní model ISO/OSI [online]. 1999 [cit. 21. listopadu 2011]. Dostupné z: [19] PETERKA, Jiˇrí. Sít’ová vrstva. 1992 [cit. 11. prosince 2011]. Dostupné z: ˇ [20] PUŽMANOVÁ, Rita. TCP/IP v kostce. 2. upr. a rozš. vyd. Ceské Budˇejovice: Kopp, 2009, 619 s. ISBN 978-80-7232-388-3. s. 52. [cit. 21. listopadu 2011]. [21] RACEK, Lukáš. Výuková animace bezpeˇcnostních mechanismu˚ IPv6 protokolu [online]. 2011 [cit. 10. kvˇetna 2012]. Bakaláˇrská práce. Masarykova 54
ˇ 5. Z ÁV ER
univerzita, Fakulta informatiky. Vedoucí práce Tomáš Rebok. Dostupné z: . [22] SATRAPA, Pavel. IPv6: internetový protokol verze 6. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, 2011. 407 s.: ISBN: 978-80-904248-4-5. s. 79-80. [cit. 1. dubna 2012]. Dostupné z: [23] SATRAPA, Pavel. IPv6: internetový protokol verze 6. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, 2011. 407 s.: ISBN: 978-80-904248-4-5. obr. 3.15, s. 82. [cit. 30. bˇrezna 2012]. Dostupné z: [24] Wikipedie: Otevˇrená encyklopedie: Relaˇcní vrstva [online]. 2011 [cit. 21. listopadu 2011]. Dostupné z:
55
A Obrázky 0 43 44
Hop by Hop options header Routing header Fragment header
50 ESP header 51 Authentication header 60 Destination options header 135 Mobility header ___________________________ 6 17 58
TCP UDP ICMP
Obrázek A.1: Hlaviˇcky a jejich hodnoty
0 1 2 3 4 5 6, 7 8 9-d e f
Reserved (Rezervováno) Interface-Local (Rozhraní) Link-Local (Linka) Reserved (Rezervováno) Admin-Local (správa) Site-Local (Místo) Unassigned (Nepřiřazeno) Organization-Local (Organizace) Unassigned (Nepřiřazeno) Global (Globální) Reserved (Rezervováno)
Obrázek A.2: Dosahy
56
A. O BRÁZKY
Obrázek A.3: Dosah v praxi [23]
8 bits
0 bits
Type = 1
16 bits
Length
32 bits
24 bits
Source link-layer address
Obrázek A.4: Volba Source link options
Internet _ _ _ _ _address _________ fe80::1 fe80::2
Physical _ _ _ _ _address _______ 00:00:00:00:00:00 11:22:33:44:55:66
Type ______ Reachable Stale
Obrázek A.5: Cache sousedu˚
57
A. O BRÁZKY 8 bits
0 bits
Type = 5
16 bits
24 bits
Length = 1
32 bits
Reserved = 0 MTU
Obrázek A.6: MTU option 8 bits
0 bits
Type = 3
16 bits
Length = 4
24 bits
Prefix Length
32 bits
L A R Reserved = 0
Valid Lifetime Preferred Lifetime Reserved = 0
Prefix
Obrázek A.7: Prefix information option 8 bits
0 bits
Type = 25/31
16 bits
Length
24 bits
32 bits
Reserved = 0 Lifetime
Addresses of IPv6 Recursive DNS Servers / Domain Names of DNS Search List
Obrázek A.8: Volby obsahující lokální DNS servery
Typ zprávy Význam zprávy 1 2 3 4 5 6
zahájení testu domácí adresy (home test init) zahájení testu dočasné adresy (care-of test init) test domácí adresy (home test) test dočasné adresy (care-of test) aktualizace vazby (binding update) potvrzení vazby (binding acknowledgement)
Obrázek A.9: Seznam hlavních zpráv pˇrenášených v hlaviˇcce mobility 58
A. O BRÁZKY
0 bits
8 bits
16 bits
32 bits
24 bits
Type = 5
Length
Authenticator
Obrázek A.10: Volba v Binding update Authorization data
0 bits
8 bits
16 bits
Home Nonce Index
32 bits
24 bits
Type = 4
Length = 4
Care-of Nonce Index
Obrázek A.11: Volba v Binding update Nonce indices
59
B Obsah Pˇriloženého CD Souˇcástí práce je pˇriložené CD, které obsahuje následující: •
Text bakaláˇrské práce ve formátu .pdf (složka bc_text)
•
Zdrojové soubory ve formátu .fla (source_files)
•
Spustitelné animace ve formátu .swf soubor menu.html (animation_files)
•
Spustitelné animace ve formátu .swf popisující IPsec od Bc. Lukáše Racka (animation_files/animation_thesis)
60
