}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Výuková interaktivní animace sít ového protokolu IPv6 BAKALÁŘSKÁ PRÁCE Jiří Kalina Brno, 2012

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Jiří Kalina Vedoucí práce: RNDr. Tomáš Rebok, Ph.D. ii

3 Poděkování Rád bych poděkoval vedoucímu mojí bakalářské práce RNDr. Tomáši Rebokovi, Ph.D. za cenné rady, velkou trpělivost a jeho čas, které mi věnoval při vypracování této bakalářské práce. Dále bych rád poděkoval své rodině a hlavně svým rodičům Bc. Jiřímu Kalinovi a Haně Kalinové, že mě podporovali po celou dobu studia a umožnili mi, abych se mohl plně věnovat studiu a tvorbě této bakalářské práce. Poděkování patří také mým spolužákům Bc. Lukáši Rackovi za udělení souhlasu použít jeho animace zabývají se IPsecem a Bc. Janovi Meravému za rady poskytnuté ohledně práce v programu Adobe Flash Professional. iii

4 Shrnutí Obsahem mojí bakalářské práce je představení funkčnosti mechanismů internetového protokolu IPv6 a jejich analýza. Následně jsou pro tyto mechanismy vytvořené výukové animace. V teoretické části popisuji referenční ISO/OSI model a historii vzniku protokolu IPv6. Dále se věnuji podrobné analýze základní hlavičky IPv6, rozšiřujícím hlavičkám, způsobům adresování, protokolu neighbor discovery, autokonfiguraci a mobilitě. Na závěr je ještě shrnuto několik bezpečnostních aspektů v IPv6. Tato část slouží především jako rozšiřující materiál k praktické části práce. V praktické části se nalézají výukové animace vytvořené v programu Adobe Flash Professional CS5. Jejich cílem je předvést fungování mechanismů formou vhodnou k výuce tak, aby je studenti byli schopni pochopit. iv

5 Klíčová slova IPv6, hlavičky, datagramy, unicast, multicast, anycast, neighbor discovery, dosažitelnost, bezstavová konfigurace, DHCPv6, mobilita, IPsec, bezpečnost, Flash v

6 Obsah 1 Úvod ISO/OSI Sít ová vrstva IPv Historie IPv Datagramy Základní hlavička protokolu IPv Zřetězení hlaviček Rozšiřující hlavičky Analýza IPv6 komunikace Adresace Zápis adresy Unicast Multicast Anycast Povinné adresy uzlu Neighbor discovery Zjišt ování linkových adres Zjišt ování dosažitelnosti souseda Autokonfigurace Bezstavová konfigurace DHCPv Mobilita Přesun v síti Získání domácího agenta Optimalizace cesty Přenos dat Návrat domů Bezpečnost IPv Výukové animace protokolu IPv Důvody pro animaci Adobe Flash Professional Ovládání animací Vytvořené animace Závěr A Obrázky B Obsah Přiloženého CD

7 1 Úvod První počítačová sít se objevila v 60. letech 20. století. Tato sít propojovala čtyři americké univerzity, rychlost měla 50 kbit/s a jmenovala se ARPANET (Advanced Research Projects Agency Network). Od poloviny 70. let se začaly počítačové sítě využívat také komerčně využívat. Do té doby sloužily výhradně k akademickým a experimentálním účelům. Mnoho výrobců začalo vytvářet vlastní sít ové produkty. Problém nastal, když se počet uživatelů zvýšil a ti se chtěli vzájemně propojit, protože zařízení výrobců byla proprietární (fungovala na různých technologiích, které vymyslel daný výrobce). Což způsobilo jejich vzájemnou nekompatibilitu a bylo nutné přijít s řešením, kdy by mohli sít ová zařízení od různých výrobců mezi sebou komunikovat. Sjednotit technologii výrobců, aby byla vzájemně kompatibilní, se povedlo v 80. letech mezinárodní standardizační organizaci ISO (International Standards Organization, správně: International Organization for Standardization) s referenčním modelem OSI. Tímto modelem se více zabývá kapitola 1.1. OSI model nahradila posléze rodina protokolů TCP/IP, které se dosud používají. Součástí TCP/IP je internet protocol. V současné době je dominantní Internet Protocol version 4 (IPv4), ale nyní jej začí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ářská práce, jejímž cílem je přehledně popsat historii vzniku a fungování protokolu IPv6. Praktickou částí práce jsou výukové animace,které prezentují fungování mechanismů IPv6. Textová část práce slouží především jako rozšiřující materiál k daným animacím. IPv6 vznikl hlavně kvůli docházejícímu adresnímu prostoru v IPv4. Při tvorbě IPv6 se však nemyslelo jen na adresní prostor, ale i na další důležité aspekty, které v základu nebyl IPv4 schopen nabídnout. Hlavními jsou: Velký adresní prostor, který by měl vydržet pokud možno napořád Tři druhy adres unicast (individuální), multicast (skupinové) a anycast (výběrové) Jednotné adresní schéma pro Internet a vnitřní sítě Zvýšení bezpečnosti zahrnutí schémat pro autentizaci, šifrování a sledování cesty k odesílateli Podpora pro služby se zajištěnou kvalitou Vysokorychlostní směrování 2

8 1. ÚVOD Automatická konfigurace (nejlépe typu plug and play) Podpora mobility Hladký přechod mezi IPv4 a IPv6 1.1 ISO/OSI Jak již bylo napsáno v úvodu, s komerčním rozmachem počítačových sítí v 70. letech byl problém s jejich vzájemnou nekompatibilitou, kterou bylo nutné vyřešit. A tohoto úkolu se chopila mezinárodní standardizační organizace ISO, která přišla s řešením s názvem Open Systems Architecture. Toto řešení ovšem nakonec nebylo schváleno a po několika dalších pokusech byl nakonec v roce 1984 schválen Reference Model for Open Systems Interconnection (Referenční model pro propojování otevřených systémů) jako norma ISO Pro většinu lidí znám jako referenční model OSI nebo též ISO/OSI model. ISO/OSI model se skládá ze sedmi vrstev, v němž každá vrstva plní určitou úlohu a využívá funkce a služby vrstvy nacházející se bezprostředně pod ní. ISO/OSI model zobrazuje obrázek 1.1. Těchto sedm vrstev se dále dělí do dvou bloků po třech vrstvách, propojených jednou spojovací vrstvou. Blok dolních třech vrstev se stará o přenos dat, zatímco druhý blok se zaměřuje na podporu aplikací. Spojovací vrstva pak má vyrovnávat rozdíly mezi možnostmi bloku nižších vrstev, a potřebami bloku vyšších vrstev [18]. Aplication layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer Transmission medium Obrázek 1.1: ISO/OSI model Aplication layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer Vrstvy ISO/OSI modelu Physical layer (Fyzická vrstva) je nejspodnější vrstvou. [6] Úlohou této vrstvy je zajištění odeslání jednotlivých bitů mezi příjemcem a odesílatelem 3

9 1. ÚVOD prostřednictvím fyzického média. Představuje elektrické, mechanické a optické rozhraní spolu s potřebnými softwarovými ovladači komunikačních portů. Na této úrovni se realizují všechny detaily týkající se přenosového média. Fyzická vrstva je ve skutečnosti pouze reálným spojením mezi dvěma komunikujícími uzly. Data link layer (Spojová vrstva) je druhá vrstva. Tato vrstva se stará o přenos rámců. Zajišt uje bezchybný přenos dat, protože fyzická vrstva se nezajímá o to, jaká hodnota bitu dorazí. O správnost přenesených dat se musí starat spojová vrstva pomocí kontrolních součtů. V případě, že data nedorazila v pořádku, si vrstva vyžádá zaslání dat znovu. Network layer (Sít ová vrstva) má na starosti směrování v komplexní síti a přenos datových jednotek od zdroje k cíli. Mezi její další úkoly patří dohodnutí kvality služby, sít ové adresování, zahajování a ukončování sít ových spojení a oznamování vzniklých chyb. Dále jsou v sít ové vrstvě sdruženy funkce, které umožňují překonat rozdíly mezi různými technologiemi v přenosových okruzích a podsítích. Tím je dosaženo konzistence služby. Sít ová vrstva poskytuje transportní vrstvě nezávislost na směrování (zajišt uje spojení mezi jakýmikoliv dvěma uzly). Při posílání paketů hlídá jejich správné pořadí a seřazuje je podle toho, jak mají být doručeny. Na této vrstvě pracují protokoly IP (IPv4 a IPv6). Transport layer (Transportní vrstva) je v pořadí čtvrtá. Transportní vrstva se zabývá komunikací mezi koncovými aplikacemi (tzv. end-to-end komunikaci). Jejím účelem je poskytovat úroveň přenosu jaká je vyžadována vyšší vrstvou. Na této vrstvě se nachází transportní protokoly poskytující spolehlivý přenos dat (TCP) a neposkytující spolehlivý přenos dat (UDP). Session layer (Relační vrstva) je pátá vrstva modelu ISO/OSI. [24] Úkolem vrstvy je organizovat a synchronizovat komunikaci mezi relačními vrstvami obou komunikujících uzlů. Umožňuje vytvoření, ukončení, synchronizaci a obnovení relačního spojení a oznamovaní výjimečných stavů. Presentation layer (Prezentační vrstva) je šestá vrstva OSI modelu. [20] Má za úkol převádět informace z aplikační vrstvy do určité jednotné reprezentace, aby bylo posléze možné v aplikaci na druhém uzlu tyto data korektně zobrazit. Mezi ukázkové transformace lze zařadit překlad znaků 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řípadně zobrazování celých čísel. Zatímco jeden stroj může čísla zobrazovat v doplňkovém tvaru, jiný je zobrazuje v přímém tvaru a převod má za úkol prezentační vrstva. Application layer (Aplikační vrstva) je poslední vrstva OSI modelu. Účelem vrstvy je poskytovat aplikačním procesům přístup ke komunikačnímu 4

10 1. ÚVOD systému a tím umožnit jejich vzájemnou spolupráci. Na této vrstvě operují kromě aplikací i aplikační protokoly. Těmi hlavními jsou WWW aplikace a jí přiřazený protokol HTTP, s protokolem SMTP a přenos souborů 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 principů. Nejznámější protokol, který z ISO/OSI prakticky vychází, je TCP/IP. Ten používá čtyři vrstvy, ISO/OSI sedm. Nejčastěji se lze s modelem ISO/OSI setkat jako s výukovým materiálem pro svou přehlednost a jednoduchost. Aplication layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer ISO/OSI Aplication layer Transport layer Internet layer Network acces layer TCP/IP Obrázek 1.2: Protokol TCP/IP 1.2 Sít ová vrstva Jelikož se bakalářská práce zabývá protokolem IPv6, který se nachází na sít ové vrstvě, je vhodné podrobněji popsat její fungování. Sít ová vrstva je třetí vrstva ISO/OSI modelu. Pod vrstvou se nachází spojová vrstva a nad ní transportní vrstva. Sít ová vrstva má hlavně na starosti směrování v síti. [19] Pokud jsou přenášena nějaká data, tak o přenos mezi uzly se stará spojová vrstva, ovšem kterému uzlu se mají data odeslat, určuje právě sít ová vrstva. Pokud jsou mezi dvěma komunikující mu uzly jiné prvky, přes které musí data projít, tak sít ová vrstva určí cestu, kudy data bude směřovat. Když data dorazí k uzlu, spojová vrstva předá tato data sít ové vrstvě, která určí, jestli data došla k cílovému příjemci. Pokud je uzel pouze průchozí, předá data zpět spojové vrstvě a oznámí jí, kam dále má data poslat. Až se takto data nakonec dostanou k cílovému uzlu. U něj potom sít ová vrstva zjistí, že data dorazila kam měla, a předá je transportní vrstvě, kde jsou data dále zpracována. 5

11 1. ÚVOD Protože pro transportní vrstvu jsou uzly vždy vedle sebe, poskytne sít ové vrstvě jen adresu koncového uzlu. Sít ová vrstva odhaduje, kterým směrem má data poslat. Na základě této adresy a s pomocí směrovacích tabulek nachází nejlepší možnou cestu k cíli. Další věcí, kterou by měla sít ová vrstva provádět, je předcházet při směrování zahlcení sítě a snažit se zajistit rovnoměrné rozdělení zátěže. 6

12 2 IPv6 IPv6 je tu s námi už poměrně dlouho, i když podle počtu lidí co používají IPv6, se může zdát, že IPv6 funguje maximálně 2 roky. Přitom specifikace protokolu IPv6 byla hotova již v roce I přes svůj pomalý rozjezd, může IPv6 nabídnout věci které IPv4 nemůže. Za všechny uvedu pár příkladů: bezstavová konfigurace, IPsec a podpora mobility. Hodí se připomenout, co předcházelo protokolu, kdysi označovanému jako IP next generation. 2.1 Historie IPv6 V úvodu jsem popsal krátce historii IPv6. V této části se jí budu věnovat podrobněji. První počítačová sít byla vytvořena v 60. letech 20. století. Touto sítí byla ARPANET, jejíž vznik byl financován ministerstvem obrany USA a měla za úkol zjistit fungování sítě pomocí přepínaných paketů a bez centrálního místa. Taková sít je schopna fungovat i v případě, že některé části jsou odpojeny (zničeny). Zároveň umožňovala vzdálený přístup k nejvýkonnějším počítačům tehdejší doby. Základem ARPANETu se staly počítače na 4 univerzitách v USA 1. Vůbec první paket byl poslán v této síti 29. října 1969 z počítače umístěného v univerzitě v Los Angeles do Stanfordu a jednalo se o pokus o přihláš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řipojit až 256 uzlů a přinesl některé služby, které se používají dosud. Např. a FTP (File Transfer Protocol). Počet připojených počítačů se postupně zvyšoval a v září 1973 bylo připojeno 40 počítačů. V témže roce se navíc připojily počítače umístěné mimo území USA a to v Oslu a v Londýně. V roce 1981 bylo připojeno celosvětově již 213 počítačů a nové se stále připojovaly. V roce 1983 se ARPANET rozdělil na vojenskou a veřejnou část. Ještě před tímto rozdělením byl 1. ledna NCP protokol nahrazen protokolem TCP/IP. Každý připojený uzel byl odpojen a znovu připojen už s novým protokolem. TCP/IP protokol nabízel oproti NCP 32 bitovou adresaci (IPv4), což znamenalo adresní prostor o velikosti připojených uzlů. Po určité době, kdy ARPANET sloužil pouze jako páteřní sít pro ostatní připojené sítě, byl v březnu 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 říká Flag Day. 7

13 2. IPV6 Protokol IPv4 nahradil NCP v ARPANETu. IPv4 je popsán v RFC 791, které vzniklo v roce 1981, 2 roky předtím než byl nasazen do provozu. Důvod, proč nový protokol má verzi 4, je ten, že verze 0 3 byly pouze vývojové, a nikdy se s nimi nepočítalo s nasazením do ostrého provozu. TCP/IP přinesl kromě většího adresního prostoru i služby ICMP, ARP, DNS, HTTP a další. Zároveň zachoval a FTP. Dnešní Internet funguje na protokolech a službách TCP/IP. Bohužel stejně jako u NCP i v IPv4 postupně docházelo místo pro nové stroje, což bylo způsobeno špatným hospodařením s IP adresami. Aby se zabránilo vyčerpání adres, přišlo se s mechanismem pro přidělování IP adres CIDR (Classless Inter-Domain Routing). Když bylo jasné, že místo stejně dojde (3. února 2011 skutečně došlo. Byl rozdán poslední blok IPv4 adres.), tak se rozhodlo o přechodu k nové verzi IP protokolu, který by měl větší adresní prostor a zároveň opravoval nedostatky, na které se přišlo v průběhu fungování IPv4. Nová verze IP začala vznikat už na počátku 90. let tehdy ještě pod názvem IPng (Internet Protocol next generation). Její základní cíle, kromě velikosti adresního prostoru, byly třeba bezpečnost, jednoduchost, robustnost, snadná správa, jednoduchá rozšiřitelnost, tunelování a mnoho dalších. Všechny požadavky jsou shrnuty v RFC V prosinci 1995 vznikl standart RFC 1883 Internet Protocol, Version 6 (IPv6) specification. Kde se už nemluví o IPng, ale přímo o IPv6. Verze IPv5 je přeskočena, protože šlo o experimentální protokol pro přenos hlasu a videa po síti (Internet Stream Protocol). RFC 1883 měla již vyřešen adresní prostor, zjednodušení hlaviček i jejich následné zřetězení a bezpečnost. Nakonec vyšla ještě jedna finální specifikace a to RFC 2460 v prosinci 1998, která některé věci upravuje či doplňuje. Tato je platná dosud. Nasazení IPv6 do provozu není až tak rychlé, jaké byly původní plány. V lednu 2012 byl počet počítačů připojujících se ke službám pomocí IPv6 pouze nějakých 0,6%. [13] Důvodů, proč je to tak málo, je hned několik. Za prvé zpětná nekompatibilita s IPv4. Uživatelé, kteří mají pouze IPv6 by se nedostali ke službám, které běží pouze na IPv4. Kvůli tomuto vzniklo několik mechanismů, které umožňují přechod ze starého protokolu na nový. V praxi se ale moc nepoužívají. Další problém je začarovaný kruh. Uživatelé nemají důvod přecházet na nový protokol, když na něm nejsou žádné služby a poskytovatelé služeb nepřechází z důvodu, že na novém protokolu nejsou žádní uživatelé. Významní poskytovatelé služeb a politici se snaží popostrčit k většímu provozu pomocí IPv6, což dokládá třeba i IPv6 Day v červnu Další důvod malého rozšíření je pomalý vývoj specifikací zejména DHCPv6. Jeho předešlá verze (DHCP) se hojně používá, proto je velmi překvapující, že se specifikace tvořila dlouhých 8 let. 8

14 2. IPV6 2.2 Datagramy Datagramy jsou základní prvky, které jsou přenášeny v rámci IPv6 sítě. Jedná se o ucelený blok dat s pevně danou strukturou. Skládá se ze základní hlavičky, za níž mohou být rozšiřující hlavičky. Za nimi následují následují přenášená data. Těmi 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ří datagram. Přestože to nemusí být dále uvedeno, všechny zprávy se zasílají v podobě datagramu Základní hlavička protokolu IPv6 Základní hlavička (Basic header) protokolu IPv6 se od své předchůdkyně liší v několika věcech. Především větší přehledností, protože hlavička v IPv6 neobsahuje žádné volby, ty mají svou vlastní hlavičku. Další věcí, která se změnila, je délka hlavičky, která má délku 40 bytů (je dvakrát delší než dřív). Formát základní hlavičky, je vidět na obrázku bits 8 bits 16 bits 24 bits 32 bits Version Traffic class Flow label Payload length Hop limit Next header Source address Destination address Obrázek 2.1: Základní hlavička protokolu IPv6 Základní hlavička se skládá z polí určité délky. Jsou to: Version (verze) specifikuje použitou verzi IP protokolu. Toto pole má délku 4 bity a jak je jistě zřejmé, její hodnotou je číslo 6. Traffic class (třída provozu)je osmibitové pole a vyjadřuje prioritu datagramu. Priorita určuje kvalitu služby, jako je rychlost nebo zpoždění. Sít ové prvky využívají jeho hodnotu pro určení způsobu zacházení s datagramem (přednostní zpracování, či odsunutí datagramu až za ostatní). V současnosti stále není možné toto zajistit, proto je hodnota tohoto pole implicitně nastavena na 0. Flow label (značka toku) slouží k identifikaci proudu datagramů, které se vyznačují stejnými vlastnostmi jako jsou odesílatel nebo příjemce. Značka 9

15 2. IPV6 toku slouží jako identifikátor pro router, aby poznal, že určité datagramy patří k sobě a zacházel se všemi stejně. Pokud datagram nepatří k žádnému proudu, je hodnota nastavena na 0. Pokud uživatel nastavuje značku toku tak je požadováno, aby hodnotu přiděloval náhodně a pamatoval všechny své předchozí toky. Payload length (délka dat) nese údaj o délce datagramu. Do délky se nezapočítává základní hlavička, ale až další hlavičky a data která následují. Tato položka je šestnáctibitová což značí, že maximální délka datagramu může být 64 KB. V případě, že je potřeba delší datagram, použije se ve volbách rozšiřujících hlaviček jumbo obsah, což umožní poslat datagram delší než 64 KB. Tato volba se příliš nepoužívá, at už z důvodu velikosti MTU (Maximum Transmission Unit), které není většinou tak velké, ale zejména proto, že jumbo obsah vadí protokolům vyšších vrstev (UDP). Next header (další hlavička) se využívá k identifikaci následující rozšiřující hlavičky. Toto pole se nachází v každé rozšiřující hlavičce. Kromě určení následující hlavičky 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 Hop limit (dosah) nahradil dřívější životnost (TTL time to Live). Hodnota pole určuje, kolik možných skoků může datagram absolvovat, než je zahozen. Každý průchod 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 cyklů při směrování (takový datagram nebude bloudit v síti do nekonečna). Poslední dvě pole, z nichž každé má velikost 128 bitů, jsou source address a destination address (zdrojová a cílová adresa) a slouží k identifikaci odesílatele a příjemce datagramu nebo prvního uzlu pokud je přítomna rozšiřující hlavička Routing (směrování) Zřetězení hlaviček Základní hlavička obsahuje jen to nejnutnější, aby mohl datagram dorazit ke svému cíli. Pokud je nutné, aby datagram prošel určitými uzly a každý uzel něco vykonal nebo je potřeba daný datagram zašifrovat, tak na to základní hlavička nestačí. Proto se rozhodlo, že rozšiřující volby budou mít vlastní hlavičku, která se bude v případě potřeby přidávat za základní hlavičku. Aby mohly uzly v síti poznat, že datagram má rozšiřující hlavičky, obsahuje každá hlavička pole next header (u rozšiřujících hlaviček je typicky první, až na ESP). Podle hodnoty v tomto poli se určuje, která rozšiřující hlavička následuje 10

16 2. IPV6 za současnou. Poslední hlavička v tomto řetězci má v next header typ nesených dat. Pokud datagram neobsahuje žádné rozšiřující hlavičky, bude mít přímo základní hlavička v poli next header typ nesených dat. Nejpoužívanější hodnoty jsou zobrazeny na obr. A.1. Kompletní seznam všech hodnot se nalézá na stránkách organizace IANA 3. Příklad zřetězení je vidět na obrázku 2.2. IPv6 Basic header Next header: 6 TCP a) Bez rozšiřujících hlaviček IPv6 Basic header Next header: 0 Hop by Hop options 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říklad zřetězení hlaviček V případě použití rozšiřujících hlaviček by mohl být průchod datagramu sítí nezanedbatelně zpomalen, pokud by se každý router na cestě musel zabývat zpracováním všech hlaviček. Proto bylo zavedeno určité pořadí zřetězení. Toto pořadí je následující: 1. Basic header (Základní hlavička 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řípadné další uvedené v routing header) 4. Routing header (Směrování) 5. Fragment header (Fragmentace) 6. Authentication header (Autentizace) 7. Encapsulating Security Payload header (Šifrování obsahu) 3. protocol-numbers.xml 11

17 2. IPV6 8. Destination options (Volby pro cíl pro konečného příjemce datagramu) 9. Mobility header (Mobilita) Toto uspořádání by mělo zajistit, aby se router zbytečně nezabýval zpracováním hlaviček, pokud pro něj nemají žádný význam. [12] Pro průchozí router má smysl zabývat se datagramem pouze, pokud za základní hlavičkou následuje hlavička Hop by hop. Ta se pozná podle next header, které má hodnotu 0. Pokud je hodnota jiná, tak se router datagramem hlouběji nezabývá, pouze ho pošle dál. Ostatní hlavičky jsou důležité pouze pro koncového nebo průběžného adresáta (který je uveden v hlavičce Routing). Průběžný adresát se zajímá pouze o hlavičky Hop by hop, Destination options a Routing. Koncový adresát se musí zabývat všemi hlavičkami. Každá rozšiřující hlavička se může v datagramu vyskytnout maximálně jednou, výjimkou je pouze hlavička Destination options, která se může vyskytnout před směrováním i mobilitou. Samotnými hlavičkami 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čku, za kterou již nenásleduje vůbec nic. Pokud datagram podle své délky obsahuje ještě nějaká data, musí být ignorována. Je-li datagram přeposílán dále, musí do něj předávající tato data zkopírovat beze změny Rozšiřující hlavičky Hlavičky obsahující volby Hlavička obsahující volby je zvláštní v tom že se jako jediná může objevit v zřetězení 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čky ukazuje obr Tato hlavička má proměnlivou délku v závislosti na velikosti pole options, které nese. Pole options představuje nejdůležitější část a každou volbu v tomto poli používá trochu jinak. Přesto mají volby jednotný formát, který je vidět na obrázku 2.4. Ten je předepsá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 bytů (option data length, délka dat). Na závěr jsou obsaženy samotné volby (option data, data volby). V option type jsou předepsány významy prvních tří bitů. Hlavička Hop by hop obsahuje následující volby Pad1, PadN, Router alert (upozornění směrovače), Quickstart (rychlý start) a Jumbo payload (jumbo obsah). Pad1 a PadN slouží pouze ke vkládání volného místa tzv. vaty, 12

18 2. IPV6 0 bits 8 bits 16 bits 24 bits 32 bits Next header Header length Options Obrázek 2.3: Formát hlavičky obsahující volby Mění se po cestě: 0 - nemění se 1 - může se změnit Option type Option data length Option data 8 bits 16 bits Co se má udělat, pokud uzel nezná tuto volbu: 00 - přeskočit a pokračovat dalšími volbami 01 - zahození datagramu 10 - zahození datagramu a odeslání ICMP odesílateli 11 - 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 prvků. Hop by hop hlavička se může vyskytovat pouze přímo za základní hlavičkou. Pad1 vynechává jeden byte a má triviální tvar, protože obsahuje pouze hodnotu 0, čí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 bytů. Zbylé byty obsahují hodnotu 0. Router alert slouží k tomu, aby routerům po cestě oznámila, že datagram nese pro ně potenciálně zajímavá data. Pokud jsou data zajímavá pro router, tak se jimi podrobněji zabývá, jinak datagram přepošle dál. Volba Router alert se pozná podle hodnoty 5. Quickstart slouží ke zvýšení propustnosti transportních protokolů, zejména TCP. Odesílatel datagramu v této volbě navrhuje rychlost, jakou by rád používal. Každý router, kterým datagram projde, může tuto hodnotu snížit na pro něj přijatelnou mez. V koncovém uzlu obsahuje tedy hodnotu přijatelnou pro každý router na cestě. Tato hodnota se čas od č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čila základní maximální velikost pro datagram. Limit pro datagram je nastaven na bytů, jelikož je hodnota velikosti umístěna v dvoubytovém poli. Což by v základu mělo představovat dostatečnou velikost pro všechna běžná použití. V případě že by někomu tato velikost nedostačovala, jumbo obsah umožňuje vytvářet datagramy o maximální velikosti bytů 13

19 2. IPV6 (délka je umístěna v čtyřbytovém poli). Při použití jumbo obsahu se délka dat v základní hlavičce nastaví na 0. Datagramům obsahujícím jumbo obsah se říká jumbogramy. Aby bylo možné použít jumbogramy musí být MTU větší než oněch bytů. Jumbo obsah vadí některým protokolům vyšší vrstvy. Například TCP i UDP mají maximální velikost pro datagram nastaven shodně na bytů. Stroje, které mají zpracovat jumbogramy, musí mít tuto velikost nastavenou na vyšší hodnotu. Hlavička Destination options obsahuje stejně jako Hop by hop hlavička, 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ři mobilitě. Mobilní uzel totiž jako zdrojovou adresu používá svou dočasnou a v této volbě informuje adresáta o své domovské adrese. Tato volba má v prvním bytu hodnotu 201. Routing header Hlavička Routing umožňuje předepsat, aby datagram na své cestě prošel různými uzly (routery) v určitém pořadí. Zároveň umožňuje uchovávat si záznam, průchodu. Při procházení není nutné, aby předepsané uzly následovaly bezprostředně za sebou, ale muže být mezi nimi libovolný počet jiných routerů. IPv6 zavedlo dva typy routing headers, typ 0 a typ 2. První typ je routing header typu 0. Formát hlavičky je zobrazen na obrázku 2.5. Že se jedná o směrování typu 0 je poznat podle pole routing type, ve kterém je hodnota 0. Pole segments left oznamuje, kolika z předepsaných uzlů již datagram prošel. Pole addresses obsahuje IP adresy uzlů kterými má datagram projít. Při použití typu 0 se jako destination address v základní hlavičce 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čce. Zároveň 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řípadě, že je při přijmutí 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čky je vidět na obrázku Tento typ nachází uplatnění pouze v mobilitě, pro kterou byl přímo definován. Jediná uvedená adresa je domácí adresa mobilního uzlu. Mobilní uzel má totiž dvě adresy, domácí a dočasnou, na které se zrovna nachází. Podrobněji se budu touto hlavičkou zabývat v kapitole 3.4. Na konec je vhodné zmínit, že hlavička typu 0 byla zakázána [2]. Hlav- 14

20 2. IPV6 0 bits 8 bits 16 bits 24 bits 32 bits Next header Header length Routing type Segments left Reserved Address [1] Address [n] Obrázek 2.5: Routing header (Hlavička směrování) ním důvodem pro zakázání typu 0 bylo možné zahlcení sítě při použití směrovacích hlaviček naplněných maximálním možným počtem adres průchozích uzlů. Čímž bylo možné způsobit, že se datagram přeposílal v síti velmi dlouho. Většinou se samozřejmě neposílá jen jeden datagram, ale mnohem více. Bylo předvedeno vytvoření datového objemu, který byl 88x větší než byla konektivita připojení [7]. Další důvod, který pomohl k odmítnutí routing header typu 0 bylo, že je možné pomocí ní procházet NATem na neveřejnou adresu. Za podmínky nastavení neveřejné adresy jako poslední adresy v routing header a adresa implicitního routeru sítě, kde se neveřejný uzel nachází, bude uvedena jako předposlední adresa v hlavičce Routing. Fragment header Fragmentace slouží k rozdělení datagramu, pokud je jeho velikost větší 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ětší než velikost datagramu. V IPv6 můž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část tohoto hlášení je i velikost MTU, které se má nastavit. Fragmetace byla v IPv4 součástí základní hlavičky, zatímco v IPv6 má přidělenou vlastní hlavičku, která je vidět na obrázku 2.6. Nejvýznamnější pole v hlavičce jsou fragment offset (posun fragmentu), M-flag (more fragments, více fragmentů) a identification (identifikace). Pole identification slouží k identifikaci paketů, které patří k sobě. V tomto poli se nalézá celé číslo, které by mělo být u každého dalšího fragmentovaného 15

21 2. IPV6 0 bits 8 bits 16 bits 24 bits 32 bits Next header Reserved Fragment offset 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ětší. V případě dosažení maximálního možného čísla, které se do daného pole vejde ( ), se pokračuje od jedničky. Fragment offset oznamuje, kam patří data v paketu v rámci fragmentovaného datagramu. M-flag oznamuje pouze, zda je daný fragment poslední v tom případě má hodnotu 0 nebo následuje další potom má hodnotu 1. Pokud musí dojít k fragmentaci, rozdělí se původní datagram na dvě části fragmentovatelnou a nefregmentovatelnou. Nefragmentovatelná část datagramu je základní hlavička a každá další hlavička až po routing header. Jakákoliv část za routing header počínaje fragment header je považována za fragmentovatelnou. Tato fragmentovatelná část je rozdělena na úseky, jejichž velikost je dělitelná 8. A zároveň dost malá aby spolu s hlavičkami, které se k nim přidají, měla menší velikost než MTU, kvůli kterému se musí fragmentovat. K těmto částem se ještě musí přidat hlavičky, aby bylo možné je odeslat. Z původního datagramu se převezme nefragmetovatelná část a udělají se v ní změny ve velikosti dat v poli (payload length). V poslední hlavičce se změní hodnota v next header na 44 a vloží se za ní fragment header. Na závěr se vloží data. Takto vytvořené fragmenty jsou odeslány příjemci, který si poskládá z příchozích fragmentů původní datagram. I když IPv6 umí normálně pracovat s fragmenty, snaží se, aby ke fragmentaci pokud možno nedocházelo. Jedním z nástrojů jak omezit fragmentaci je požadavek na minimální velikost MTU v IPv6. IPv6 protokol obsahuje více hlaviček než je v této kapitole zmíněno. Těmi se budu zabývat v částech které tyto hlavičky využívají. ESP header a Authentication header jsou v kapitole 3.5. Mobility header se nalézá v kapitole

22 3 Analýza IPv6 komunikace Tato část slouží jako doplňkový materiál pro důkladný popis mechanismů, pro které byly vytvořeny výukové animace. Většina mechanismů které jsou zde popisovány v sobě nenesou klasická data typu TCP a UDP. Tyto mechanismy používají zpravidla ICMP zprávy, které slouží k výměně informací nutných pro provoz IPv6. I když to nemusí být zmíněno, všechny zprávy jsou přenášeny prostřednictvím datagramu. 3.1 Adresace Adresy v IPv6 prošly celkem razantní proměnou. Změnila se jejich forma, zvětšil se adresní prostor, přibyl jeden adresní typ a jeden zmizel. Adresy v IPv6 se přidělují rozhraním, stejně jako tomu je v IPv4. Za rozhraní se dá považovat sít ová karta, nikoliv počítač. Novinkou v IPv6 je, že každé rozhraní musí mít více adres. A na každé adrese musí přijímat příchozí komunikaci. V IPv6 existují tři základní typy adres s různým chováním. Tyto jsou unicast, multicat a anycast. Unicast je základní typ, se kterými se lze setkat nejčastěji. Komunikace probíhá mezi dvěmi konkrétními uzly. Multicast je určen k adresování skupiny uzlů, kde data odeslaná na multicastovou adresu, musí být doručena každému uzlu, který je č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áří jako unicastová, ale za touto adresou se skrývá skupina zařízení. Data poslaná na tuto adresu jsou doručena pouze jednomu uzlu ve skupině Zápis adresy IPv4 adresa je 32-bitová a vypadá takto Adresa se píše v desítkové soustavě do 4 bloků oddělených tečkami, přičemž v každém bloku je možné mít čísla od 0 do 255. Což dává dohromady přes 4 mld. různých kombinací. Adresa v IPv6 je 128-bitová neboli 4 násobně delší. Používá šestnáctkovou soustavu a obsahuje 8 bloků, v každém bloku 4 znaky. Ty jsou odděleny dvojtečkou. Ve výsledku to dává 3, různých adres. Příkladem IPv6 adresy může být: 2001:71d8:8e01:1230:54a9:ff7b:0fe1:0001. Od začátku se očekávalo, že se bude striktně používat DNS, takže uživatelé 17

23 3. ANALÝZA IPV6 KOMUNIKACE nebudou muset zadávat do adresního řádku tuto hrůzu. Bohužel ušetřeni nejsou správci sítě, kteří 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ěrně často vyskytuje číslo 0, tak se všechny pravidla týkají právě tohoto čísla. První pravidlo je, že je možné vynechat počáteční nuly v každém bloku a blok samých nul lze zapsat jako jednu nulu. Pro pří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řípadě půjde stejná adresa zkrátit až na 123:5310::fe:ab48:3310. Nulu na konci bloku ani uprostřed nelze vynechat Pokud by se vynechala nula v bloku :5310:, vzniklo by :531:, ale to neznamená :5310:, nýbrž :0531:. V případě, ž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 bloků, lze takto nahradit pouze jeden z nich, jinak by nebylo zjistitelné, jak vypadala původní adresa v nezkráceném tvaru. Napří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řesně určit, jak původní adresa vypadala. Velká variabilita zápisu způsobila, že bylo příjato RFC 5952 A Recommendation for IPv6 Address Text Representation. Který definuje kanonický tvar zápisu IPv6 adresy. Pravidla pro vytvoření kanonického tvaru jsou [14]: Počáteční nuly v bloku čtveřice se musí vždy vynechat. Zápis :: se musí použít tak, aby měl co největší efekt na zkrácení a musí obsáhnout všechny sousedící bloky nul. Je nepřípustné nechat : 0:: nebo ::0:. Pokud existují dvě stejně dlouhé skupiny nulových bloků, musí se zkrátit první zleva. Dále není povoleno použít :: na jediný nulový blok ten musí zůstat vždy ve tvaru :0:. Pro příklad adresa 2001:db8:0:1:1:1:1:1 musí zůstat 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é číslice reprezentované písmeny pouze malými znaky. Toto pravidlo je určeno také proto, aby nedochá- 18

24 3. ANALÝZA IPV6 KOMUNIKACE zelo k omylům s některými potenciálně zaměnitelnými číslicemi ( 0 a D případně 8 a B ). Často se lze v IPv6 setkat se zápisem části adresy, na jejímž konci je lomítko a za ním číslo. Tímto zápisem se označují prefixy. Prefix vyjadřuje příslušnost k určité síti a stejný prefix mají všechna rozhraní v dané síti. Délka prefixu může být u každé sítě jiná, záleží s jakou přesností je na něj nahlíženo. Krátký prefix může značit určitého poskytovatele Internetu, zatímco delší bude spíše značit určitou podsít. Zápis prefixu se řídí schématem CIDR (Classless Inter-Domain Routing). A podle něj je zápis následovný: IPv6Address/PrefixLength. Délka prefixu oznamuje, kolik bitů od začátku adresy patří do určitého prefixu. Pokud vypadá adresa třeba takto fe80::/10 znamená to, že do prefixu patří prvních 10 bitů. Názorně je to takto: prefix fe80::/10 má zápis v bitové podobě ::/10 a z něj se vezme prvních 10 bitů Prefix lze vzít i z části bloku. Do tohoto prefixu nepatří třeba závěrečná nula, ale musí být napsána. Pokud by nebyla a zápis prefixu by vypadal takto fe8::/10 mělo by se za to, že prefix má nezkrácený tvar 0fe8::/10 a vzalo by se z něj 10 bitů, neboli což už není stejný prefix. Samozřejmě lze napsat i celou adresu a z ní vzít prefix. Jelikož nás při zjišt ování prefixu nezajímá to, co je za prefixem, tak se bere jako by za prefixem následovaly samé nuly fe80::/ Unicast Unicast v sobě sdružuje hned několik typů adres. První a zároveň nejdůležitější jsou global unicast addresses (globální individuální adresy). Tyto adresy zabírají největší adresní prostor, i když v současnosti je jim přidělen pouze adresní prostor s prefixem 2000::/3 (001 binárně). Tyto adresy identifikují konkrétní uzel v rámci celého Internetu a už podle názvu je jasné, že jsou celosvětově jedinečné. Jak globální adresy vypadají je vidět na obrázku 3.1. Global routing prefix (globální směrovací prefix) se skládá z několika 16 bitových bloků podle toho, kdo dané bloky spravuje. Organizace IANA (Internet Assigned Numbers Authority), která má na starosti celkově adresy, spravuje prvních 16 bitů a je jen na ní, jaké adresy se budou používat. IANA přiděluje druhých 16 bitů jednomu z RIR (Regional Internet Registry). Celkem jich je 5 1. A ti zase přidělují bit LIR (Local Internet Registry). Těmi 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

25 3. ANALÝZA IPV6 KOMUNIKACE LIR, který má k dispozici určitý prefix, přidělí koncovým zákazníkům určitou část prefixu se stejným začátkem. Tento přístup má zajistit agregaci směrovacích údajů, tak aby byla celá sít poskytovatele i s jeho zákazníky popsat konkrétním prefixem. Tato část adresy je také nazývaná public topology (veřejnou topologií). Druhá část je subnet ID (identifikátor podsítě) nebo také jinak site topology (místní topologie). Běžná délka subnet ID je 16 bitů a umožňuje tak rozlišit až různých podsítí. Tato část je pod správou místní sítě nejčastěji u koncového uživatele. Dohromady musí mít global routing prefix spolu s subnet ID 64 bitů. Je možné setkat se se subnet ID menším, než je udávaných 16 bitů. V tomto případě bývá subnet ID 8 bitů nebo může být dokonce nulové. Část, kterou spravuje LIR je pak o těch 8 nebo 16 bitů delší. Tento pří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ří local link addresses (lokální linkové adresy). Local link addresses mají největší smysl u vnitřních mechanismů IPv6, kde pomocí nich dochází k výměně zpráv sloužících ke konfiguraci. Lze je poznat celkem snadno. Mají totiž vyhrazen vlastní prefix, stejně jako jej měly v IPv4 ( /16). V IPv6 je prefix fe80::/10. Za tímto prefixem následuje 54 bitů nulových. A na konci následuje interface ID. Prvních 64 bitů adresy se oficiálně tváří jako adresa sítě či podsítě, ale neslouží ke směrování kvůli omezení dosahu daného prefixu pouze na linku. 2 Výhoda těchto adres je v tom, že každý počítač je schopen si je vygenerovat, aniž by věděl něco o síti, ke které je připojen. V případě připojení více počítačů tímto způsobem v jedné lince, budou schopny v dané síti fungovat pouze na základě této adresy a nebudou ke svému provozu potřebovat nic kromě switche. Router ani DNS server není potřeba, ale způsob komunikace bude značně komplikovaný kvůli nutnosti zadávat pří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ění v případech, kdy je potřeba mít jednu sít, ale místa, která mají být v síti připojena, nejsou fyzicky na jedné lince. V tomto případě přichází na řadu právě unique local addresses, které přiřadí těmto místům stejný prefix a počítače si potom budou 2. Dosah má smysl především pro multicast, kde se mu budu věnovat, zde jsem ho pouze zmínil. 20

26 3. ANALÝZA IPV6 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říznak L (8. bit), který určuje, zda byl prefix generován lokálně (L=1) nebo jinak (L=0) 3. Jelikož jsou v současnosti všechny unique local addresses generovány lokálně, tak se dá říct, že je prefix fd00::/8. Za prefixem následuje 40 bitů tvořících global ID (globální identifikátor), ten je náhodně vygenerován. Za těmito 48 bity se nalézá 16bitový subnet ID. A na konci opět interface ID. Záměrně 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í část adresy, má konstantní délku 64 bitů a identifikuje konkrétní stroj v rámci podsítě. Interface ID je schopen si vygenerovat konkrétní stroj sám nebo mu může být přidělen správcem sítě. Záleží, jestli se použije bezstavová konfigurace nebo DHCPv6. V případě bezstavové konfigurace se pro vygenerování identifikátoru používá modified EUI-64 (modifikované EUI-64) nebo je kryptograficky vygenerován z veřejného klíče. Nejběžnější je první způsob. V případě DHCPv6 je identifikátor přidělen náhodně. Více se interface ID věnuje kapitola 3.3. Poslední skupinu v unicastu tvoří adresy obsahující IPv4 adresy, obrázek 3.1. Tyto adresy může využívat nějaký přechodový mechanismus, který potřebuje vyjádřit adresy z IPv4. Těchto typů adres vzniklo v historii několik. První byly IPv4-compatible addresses (IPv4 kompatibilní adresy) ty se skládaly z 96 nulových bitů a za nimi následovala IPv4 adresa. IPv4-compatible addresses byly nahrazeny IPv4-mapped address (IPv4 mapované adresy) ty měly prvních 80 bitů nulových, za nimi 16 jednotkových bitů a nakonec IPv4 adresa. V současnosti se používají IPv4-embedded addresses (adresy s vloženým IPv4). IPv4-embedded addresses je možné rozdělit do dvou druhů podle přiděleného prefixu. První druh umožňuje vyhradit část lokálního prostoru s tím, že bit musí být nulový. Za něž přijde IPv4 adresa. U druhého druhu se přiděluje univerzální prefix 64:ff9b::/96. Při použití druhého způsobu je možné napsat IPv4 adresu v jejím obvyklém tvaru (V desítkové soustavě s oddělenými bajty tečkou.). Použiji třeba adresu , která by vypadala následovně 64:ff9b:: U prvního druhu se musí IPv4 adresa převézt do tvaru odpovídajícímu IPv6 (64:ff9b::93e6:3149). Způsob převedení do IPv6 tvaru ukážu nyní na příkladu právě s IPv4 adresou Každý blok je rozepsán do dvojkového tvaru (na bity). 3. Zatím není specifikováno, ale očekává se, že bude přidělován nějakou autoritou. 21

27 3. ANALÝZA IPV6 KOMUNIKACE Následně jsou bity uskupeny do čtveřic a potom převedeny do šestnáctkové soustavy. Ve výsledku adresa vypadá následovně 93e6: bits 45 bits 001 Global Routing Prefix Public topology Global Unicast Address 16 bits Subnet ID Site topology Link Local Address 10 bits 54 bits fe80::/10 7 bits 1 bit 40 bits L Global ID fc00::/7 Unique Local Address 16 bits Subnet ID 64 bits Interface ID Interface identifier IPv4-embedded Address 96 bits Prefix 32 bits IPv4 Address Obrázek 3.1: Typy unicastových adres Multicast Multicast slouží k odeslání dat skupině uzlů. Ale na rozdíl od unicastu při poslání více počítačům projde linkou pouze jednou (U unicastu by se data odeslala tolikrát, kolik by bylo žadatelů.). Hlavní využití nachází především u streamování televizního vysílání, internetových rádií a videokonferencí v reálném čase. Multicast není žádnou novinkou v IPv6, nebot se úspěšně používá již v IPv4. Základní formát multicastové adresy je zobrazen na obrázku bits 4 bits 4 bits 112 bits R P T Scope Group ID ff00::/8 Obrázek 3.2: Formát multicastové adresy 22

28 3. ANALÝZA IPV6 KOMUNIKACE Že se jedná o multicastovou adresu se pozná podle prvního bajtu, ten je ff a tvoří obecný prefix ff00::/8. Za ním následuje čtveřice jednobitových příznaků, ty dále konkretizují použití a formát adresy. První příznak je rezervován pro pozdější použití a musí být nastaven na nulu. Za příznaky je pole scope (dosah). Scope má délku 4 bity a určuje jaký rozsah působnosti má daná multicastová skupina, viz. obrázek A.2. Na konci adresy je group ID (Adresa skupiny), ta má délku 112 bitů a její tvar je závislý na příznacích, proto se jimi budu zabývat současně. Dosah adres se používá k nastavení rozsahu působnosti adres a vymezuje topologickou oblast, v níž je multicastové adresa jednoznačná. Definovaných hodnot rozsahu je 9 a 3 z nich jsou rezervované. Dalších 7 hodnot je volně k dispozici a ISP nebo správce sítě s nimi může volně nakládat, ale měl by zachovat určité členění, kde větší číslo znamená dosah do větší části Internetu. Takže by se nemělo stát, že správce sítě v nějaké organizaci nastaví dosah adresy určené pro určité místo (Site scope) nad hodnotu 8. Dobře je vidět jak by takové členění dosahu mělo vypadat na obrázku A.3. Z obrázku je patrné, že v něm jsou určité zóny podle dosahu, a je vidět, že zóny o stejném rozsahu se nepřekrývají a zóny s nižším rozsahem nepřekročí hranici zóny s větším rozsahem. Co konkrétně znamenají jednotlivé dosahy, které jsou přesně specifikovány, popíšu nyní. 1 (Interface) Tento dosah nepřekročí jediné rozhraní (PC). Jeho využití je pro loopback(lokální smyčka). 2 (Link) Tento dosah nepřekročí konkrétní fyzickou sít (např. ethernet). Tento dosah by se dal přirovnat k běžné domácnosti. 4 (Admin) První dosah který musí být již nakonfigurován správcem, může totiž obsahovat více než jednu linku. Zpravidla se jedná o podsít. 5 (Site) Tento dosah představuje část sítě v organizaci, která se nachází v jedné geografické lokalitě. Příkladem mohou být jednotlivé fakulty univerzity. 8 (Organisation) Pokrývá několik míst náležejících jedné organizaci. Například celá univerzita nebo firma s pobočkami v různých městech. e (Global) Celosvětový dosah (celý Internet). Základním příznakem je příznak T (transient). Tento příznak definuje, zda je daný group ID přidělen trvale nebo dočasně. Pokud je T=0, znamená to, že se jedná o trvalou neboli well-known adresu. Tyto adresy přiděluje 23

29 3. ANALÝZA IPV6 KOMUNIKACE IANA. Pokud je ovšem T=1, tak se jedná o dočasnou adresu, kterou si mohou vygenerovat všichni podle potřeby. V případě trvalé skupiny je group ID stále platný a nezávislý na dosahu. Jako ukázka může posloužit komunikace s routery. Pokud počítač chce komunikovat s routery, používá multicastovou adresu ve tvaru ff0x::2, kde x představuje různé dosahy. Pokud počítač zašle dotaz na ff02::2, tak se bude týkat pouze routerů, kteří sídlí na lince. Na adrese ff08::2 jsou to už všechny routery v dané organizaci, ale pořád je to adresa vyhrazená pro zaslání na všechny routery. Zatímco, pokud by byla multicastová adresa ve tvaru třeba ff12::2, tak nemá žádnou spojitost s adresou ff02::2 (všechny routery na lince) ani s případnou stejnou adresou ovšem vytvořenou jinde. Dokonce nemá žádný vztah s adresou, která by byla stejná až na dosah (např. ff1e::2). T=1 má svůj význam ještě navíc v souvislosti s ostatními příznaky. Příznak P značí adresy, které vznikají z unicastové adresy (tzv. Unicast- Prefix-based IPv6 multicast addresses). [9] Pokud je P=1 tak musí být i T=1 jelikož se jedná o dočasnou skupinu. Účelem těchto adres má být zajištění snazšího generování adres, aniž by se muselo komplikovaně zjišt ovat, jestli daná adresa již někde neexistuje. To je zaručeno vložením prefixu unicastových adres z dané sítě. Příznak P definuje jiný tvar group id. Tvar adres založených na unicastu je zobrazen na obrázku 3.3. U těchto 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 může mít maximální délku 64 bitů. Unicast-Prefix-based IPv6 Multicast Address 8 bits 4 bits 4 bits 8 bits 8 bits max. 64 bits max. 32 bits R 1 1 Scope Reserved =0 Plen Network prefix Group ID ff30::/12 Source Specific Multicast address 8 bits 4 bits 4 bits 8 bits 8 bits 64 bits 32 bits R 1 1 Scope Reserved =0 Plen =0 Network prefix =0 Group ID ff30::/12 Link-Scoped IPv6 Multicast address 8 bits 4 bits 4 bits 8 bits 8 bits 64 bits 32 bits R 1 1 Scope Reserved =0 Plen =ff Interface ID Group ID ff30::/12 Obrázek 3.3: Multicastové adresy vzniklé z unicastu. Do adres definovaných příznakem P spadají Source Specific Multicast 24

30 3. ANALÝZA IPV6 KOMUNIKACE (SSM) adresy, obrázek 3.3. Tyto adresy mají využítí u přenosu dat z jednoho zdroje skupině příjemců, např. u internetového rádia a televize. SSM adresy mají přidělen prefix ff3x::/96 (x značí různý dosah) a 32bitové group ID. Jednoznačnost je zaručena 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ětší než za linku (hodnota scope je 0-2). Výhoda těchto adres je, že si je může generovat každý počítač a protože součá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 bitů náleží group ID. Zatím poslední definovaný pří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ě, rendezvous point, RP).[10] RP adresa vychází z adresy založené na unicastu. Její tvar je na obrázku 3.4. Změna je hlavně v poli RIID (RP Interface ID). Toto pole obsahuje poslední 4 bity z interface ID. A podobně jako u předchozích adres, i zde je potřeba, aby když R=1 tak i P=1 a T=1. Hlavní úlohu v něm hraje tzv. shromaždiště (RP), kde je umístěn distribuční strom skupiny. Výhodou těchto adres je jednoduché vytváření jednoznačných adres, protože jediné co je nutné, je udržet si pořádek v adresách pouze v rámci shromaždiště. Dále možnost odvodit si adresu shromaždiště z multicastové adresy a tím pádem i místo kde se do skupiny přihlásit. Embedding the Rendezvous Point Address 8 bits 4 bits 4 bits 4 bits 4 bits 8 bits 64 bits 32 bits Scope Res=0 RIID Plen Network prefix Group ID ff70::/12 Obrázek 3.4: Adresa obsahující shromaždiště, Rendezvous point, RP Multicastová adresa se nemůže vyskytovat na místě odesílatele datagramu a nesmí se také vyskytovat v rozšiřující hlavičce Routing Anycast Anycast tvoří novinku v adresaci. Funguje způsobem, který umožní, aby se za jednu adresu schovalo více strojů (jako v multicastu), ale datagram byl doručen pouze jednomu konkrétnímu stroji. Základní princip fungování anycastu spočívá ve standardních směrovacích principech. Pomocí nich je zajištěno, že dotaz doputuje k nejbližšímu stroji ze skupiny provozující 25

31 3. ANALÝZA IPV6 KOMUNIKACE danou službu. Nejlepší příklad anycastu jsou DNS servery. Kořenových DNS serverů je 13 a za jejich adresami se skrývá přibližně 250 serverů rozmístěných všude možně po sítí. Tímhle je zajištěno, že dotaz odeslaný na anycastovou adresu doputuje k nejbližšímu serveru. Ve výsledku dochází k rovnoměrnějšímu rozdělení zátěže, protože z určité oblasti dorazí dotaz k určitému serveru. Tenhle princip umožní kromě rozdělení zátěže rychlejší odezvu díky kratší cestě mezi klientem a serverem, zvýšení výkonu a spolehlivosti služby a lepší odolnost vůči DoS (Denial of Service) a DDos (Distributed Denial of Service) útokům. Protože útočníci nejsou schopni dosáhnout dál než na servery, které obsluhují oblast, ve které se nacházejí. Spolehlivost služby je zajištěna tím, že v případě výpadku nejbližšího stroje s danou anycastovou adresou, je schopen jeho činnost převzít jiný stroj ze skupiny, i když na něj bude vyvíjena větší zátěž. Ne vždy je to tak ovšem jednoduše možné. Využití anycastu snižuje i počet adres na nichž je daná služba poskytována. Dobrý příklad jsou DNS servery. U nich by nebylo moc dobré, kdyby měl seznam adres kořenových DNS serverů několik stovek položek, z nichž by se pravidelně každý měsíc několik měnilo. Anycastové adresy nemají přiděleno 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ější je to uvnitř této skupiny (sítě). Skupina má vlastní prefix sítě, který musí obsáhnout všechna rozhraní v této anycastové skupině. To znamená, že pokud se všechny rozhraní nalézají v jedné podsíti, bude jako prefix použita adresa této podsítě. Na druhou stranu mohou být členové skupiny rozmístěny tak nešt astně, že prefix bude pouze 2000::/3. Rozsah skupiny má zásadní vliv na konfiguraci. Uvnitř každé sítě, ve které se nalézá anycastová skupina, musí mít anycastová adresa svůj vlastní směrovací záznam, který v jednotlivých routerech ukazuje vždy na nejbližšího člena skupiny. V případě prefixu 2000::/3 by mělo za následek, přidání adresy mezi globální směrovací informace. Tudíž potenciálně extrémní navýšení směrovacích tabulek uvnitř páteřních routerů. Z tohoto důvodu je použití globálních anycastových adres silně omezeno. Zajímavé použití představuje anycast v rámci jediné podsítě. Zde neplatí pravidlo o doručení k nejbližšímu členovi, protože všichni členové jsou z pohledu směrování stejně daleko. Ale představuje systém, kdy uvnitř podsítě poskytují členové konkrétní služby a je jedno se kterým z těchto členů chce počítač komunikovat. Tyto anycastové adresy mají podobu pevně definovaných interface ID za prefixem dané podsítě. V současnosti jsou definovány zatím jen dvě 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

32 3. ANALÝZA IPV6 KOMUNIKACE fdff:ffff:ffff:fffe, která je určena pro home agents, jejichž využití se týká mobility. Bohužel i anycast trpí neduhy. Nejvýznamnější problém se týká stavových protokolů, především TCP a služeb uchovávajících si stavy na serverech. Problém může nastat při zasílání série dat na anycastovou adresu. Kdy při výpadku jednoho serveru sice data budou proudit na jiný server, ale ten v případě stavové služby nemusí mít uložen stav dotyčného komunikujícího počítače. V případě TCP pak nastává problém, když část dat dorazí k jednomu členovi skupiny a další část dat jinému. Tím vznikne zbytečně velký provoz na síti, z důvodu vyžádání znovu-zaslání dat. Tento problém by šel řešit způsobem, kdy by odesílatel na počátku pomocí anycastu zjistil unicastovou adresu a na tu potom směroval svou komunikaci. Tím by ovšem ztratil anycast svůj smysl a byl by zranitelnější i v případě DoS a DDoS utoku. Další problém se ukrývá přímo v páteřních internetových routerech. Ty většinou odmítají příliš dlouhé prefixy a tedy i záznamy pro anycastové adresy. Dále při změnách ve skupině, mohou být změny následně vyhodnoceny jako chyba na straně zařízení a poté bude daná adresa zablokována. Nejlepší využití najde anycast u služeb, kde nejsou stavové informace potřeba jako výše zmíněný DNS, kdy každý dotaz a odpověd je zaslán v jednom datagramu a je jedno ke kterému DNS serveru se dotaz dostane Povinné adresy uzlu Na začátku kapitoly bylo zmíněno, že každé rozhraní musí mít více adres a na každé přijímat komunikaci. Což je přímo dáno ve specifikaci. To vše z důvodu různých mechanismů, které posílají data na různé adresy. Povinné adresy musí mít počítač následující [22]: Lokální linková adresa pro každé rozhraní Všechny individuální a výběrové adresy, které mu byly přiděleny Lokální smyčka (loopback) Skupinové adresy pro všechny uzly Skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální a výběrové adresy Všechny skupinové adresy, jejichž je členem Další kdo musí přijímat na více adresách, je router. Ten se musí hlásit ke stejným adresám jako počítač. A ještě navíc k těmto dalším dvěma: 27

33 3. ANALÝZA IPV6 KOMUNIKACE Výběrová adresa pro směrovače v podsíti (pro každé rozhraní, kde funguje jako směrovač) Skupinové adresy pro všechny směrovače 3.2 Neighbor discovery Neighbor discovery neboli objevování sousedů slouží v protokolu IPv6 k řešení jednoho známého problému počítačových sítí. Tímto problémem je, jak poslat data někomu kdo sídlí ve stejné lokální síti (například ethernetu) a jediné co znám je IP adresa daného stroje. K tomu aby šla data odeslat, nestačí znát pouze IP adresu, ale je potřeba znát fyzickou adresu stroje, kterému se mají data odeslat. A to právě řeší Neighbor discovery. IPv4 k tomuto účelu 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 Stroj, který má danou adresu, odesílateli odpověděl a přiložil k odpovědi svou fyzickou adresu. V IPv6 je tento mechanismus definován v RFC 4861 Neighbor Discovery for IP version 6 (IPv6) jako základní součást IP protokolu. A na rozdíl od ARPu v IPv4, který řešil pouze hledání linkových adres, neighbor discovery řeší další problémy: Zjišt ování linkových adres v jedné lokální síti Aktualizace a zjišt ování změn v linkových adresách Hledání směrovačů Zjišt ování parametrů sítě a údajů pro automatickou konfiguraci Dosažitelnost souseda Detekce duplicit Pro svoji činnost využívá neighbor Discovery sedm typů ICMP zpráv. Pět z nich jsou: Neighbor solicitation message (Výzva sousedovi) Neighbor advertisement message (Ohlášení souseda) Router solicitation message (Výzva směrovači) Router advertisement message (Ohlášení směrovače) Redirect (Přesměrování) 28

34 3. ANALÝZA IPV6 KOMUNIKACE Zbylé dvě slouží pro bezpečnost respektive pro bezpečné objevování sousedů neboli SEND (SEcure Neighbor Discovery) Certification path solicitation (Žádost o certifikační cestu) Certification path advertisement (Ohlášení certifikační cesty) Zjišt ování linkových adres Zjišt ování linkových adres vychází přímo z ARP protokolu. Změny nastaly pouze u názvů 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čný prefix ff02:0:0:0:0:1: ff00::/104. Za tento prefix připojí uzel hledající linkovou adresu určitého uzlu posledních 24 bitů z hledané IP adresy. V případě, že hledá linkovou adresu pro uzel s IP adresou fe80::1234:5678 vezme část 34:5678 a připojí jí za daný prefix. Ve výsledku bude zasílat svůj dotaz této multicastové adrese ff02::1:ff34:5678. Pokud počítač bude shánět linkovou adresu počítače, u nějž zná pouze IP adresu, bude postup následovný. Vytvoří ICMP zprávu neighbor solicitation (NS) obr. 3.5 a odešle jí na IP adresu, kterou vytvoří podle postupu v předchozím odstavci. Součástí NS může být i volba, obr. A.4, která ohlašuje linkovou adresu odesílatele, aby příjemce rovnou věděl, kam má zaslat odpověd a nemusel sám ještě zjišt ovat linkovou adresu tazatele. 0 bits 8 bits 16 bits 24 bits 32 bits Type = 135 Code = 0 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říjemce tím, kdo je hledán, tuto výzvu ignoruje. Uzel, jehož posledních 24 bitů v IP adrese se shoduje s koncem multicastové adresy, vytvoří ICMP zprávu neighbor advertisement (NA), obr. 3.6, a do voleb přidá svou vlastní linkovou adresu. Tuto zprávu poté odešle už přímo dotazujícímu se uzlu a ten si uloží linkovou adresu do své cache sousedů. V NA se nacházejí 3 příznaky routing 29

35 3. ANALÝZA IPV6 KOMUNIKACE flag, solicitation flag a override flag. Tyto příznaky určují, jestli je odesílatel router (routing flag) nebo jestli je odesílání NA vyžádané (solicitation flag), případně zda má toto ohlášení přepsat existující údaje uložené v cache sousedů (override flag). 0 bits 8 bits 16 bits 24 bits 32 bits Type = 136 Code = 0 Checksum R S O Reserved = 0 Target address Options Obrázek 3.6: ICMP zpráva Neighbor advertisement (NA, Ohlášení souseda) Uzel může sám od sebe zaslat nevyžádanou NA zprávu. To dělá v případě, že u něj došlo ke změně linkové adresy a chce o tom dát okolí vědět. Potom zašle několik NA na multicastovou adresu ff02::1, na které poslouchají všechny uzly v síti. Ty uzly, které mají ve své cache sousedů záznam s danou IP adresou odesílatele ohlášení, si daný záznam aktualizují a ostatní zprávu ignorují Zjišt ování dosažitelnosti souseda Při práci se sousedy si každý uzel udržuje aktuální stav dosažitelnosti těch, se kterými komunikuje. Dosažitelnost se určuje dvěma způsoby. První způsob je, že vyšší vrstva potvrdí dosažitelnost, pokud probíhá komunikace. Druhý způsob je, že uzel zjišt uje dosažitelnost vlastními silami. Základ neighbor unreachability detection, tvoří pět různých stavů v cache sousedů, které jsou u každé položky a určují, v jaké fázi dosažitelnosti se konkrétní uzel nachází. První stav incomplete se vyskytuje pouze na počátku zjišt ování dosažitelnosti a oznamuje, že soused byl zrovna přidán do cache sousedů a už podle názvu incomplete (nekompletní) je jasné, že něco chybí. Přesněji, když se uzel nachází v tomto stavu, tak mu byla zaslána ICMP zpráva NS a dosud nedorazila odpověd NA. Jakmile dorazí odpověd, tak se hodnota změní z incomplete na reachable (dosažitelná). Pokud by odpověd nedorazila, znamená to, že daný uzel není dosažitelný a položka o něm bude z cache sousedů 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

36 3. ANALÝZA IPV6 KOMUNIKACE trvalý. Doba, po kterou je daný uzel považován za dosažitelný, se určuje v každé síti pomocí router advertisement. Pokud tato doba uplyne dříve, než stačí přijít nové potvrzení o dosažitelnosti, mění se hodnota stavu na stale (prošlá). Stav stale ještě neznamená, že je něco špatně. Značí to jen, že s daným uzlem nebylo chvíli komunikováno. V tomto stavu zůstává záznam v cache sousedů do té doby než je potřeba odeslat uzlu nějaká data. Když je potřeba data odeslat, odešlou se stejně, jako by byl daný uzel dosažitelný a provede se změna stavu na delay (odložená). Ve stavu delay se nachází uzel do té doby, než vyšší vrstva potvrdí, že dorazila odpověd a potom se stav změní na reachable. [16] Nebo odpověd nedorazí a uzel bude muset zjistit dosažitelnost vlastními silami na IP vrstvě a přitom změní stav na probe (testovaná). Ve stavu probe se dosažitelnost zjišt uje stejně jako ve stavu incomplete a to pomocí zpráv NS a NA z principu hledání linkových adres. V tomto případě zašle uzel několik NS, a když dostane odpověd v podobě NA, tak změní stav na reachable. Pokud se odpovědi nedočká, považuje uzel za nedosažitelný a je odstraněn z cache sousedů. Jak může vypadat cache sousedů, je vidět na obr. A Autokonfigurace Pokud chce stroj připojený k síti komunikovat, musí mít přidělenou adresu. V případě lokální komunikace mu postačuje, aby si sám vygeneroval local link address pomocí modified EUI-64. V případě komunikace v Internetu potřebuje mít adresu, která bude přístupná z Internetu. K tomu potřebuje mít přidělen prefix sítě, ve které se nachází a znát další informace nutné pro komunikaci. Tyto informace jsou mu poskytnuté pomocí autokonfigurace. Autokonfigurace zná dva způsoby jak počítači tyto informace poskytnout. [1] První způsob je bezstavová konfigurace stateless configuration. Druhý způsob se jmenuje stavová konfigurace (statefull configuration) pomocí DHCPv6. Výraz stavová konfigurace se ovšem moc nepoužívá a místo něj se hovoří pouze o DHCPv Bezstavová konfigurace Základním mechanismem v bezstavové autokonfiguraci je router advertisement (RA, Ohlášení směrovače). RA odesílá každý router do všech sítí ke kterým je připojen. Odesílání probíhá v náhodných intervalech, aby se zamezilo odeslání ohlášení z více routerů ve stejnou dobu, což by mohlo mít 31

37 3. ANALÝZA IPV6 KOMUNIKACE za následek zmatek v síti. RA obsahuje informace o síti a musí je přijímat každý uzel v dané síti a řídit se podle něj. Formát RA je vidět na obrázku bits 8 bits 16 bits 24 bits 32 bits Type = 134 Code = 0 Checksum Cur Hop Limit M O H Reserved = 0 Router Lifetime Reachable Time Retrans Timer Options Obrázek 3.7: Router advertisement (RA, Ohlášení směrovače) RA je informační typ ICMP zprávy. Pole type (typ) určuje, o jaký typ zprávy se jedná. RA má v tomto poli hodnotu 134. Pole code (kód) obsahuje implicitně hodnotu 0. A pole checksum (kontrolní součet) slouží jako kontrola, že paket došel v pořádku. Cur hop limit oznamuje jakou hodnotu má odesílající uzel ze sítě vložit do pole hop limit v základní hlavičce. Za tímto polem následuje několik příznaků. Příznak M neboli managed address configuration (Stavová konfigurace adres) oznamuje, zdali se má pro konfiguraci použít DHCPv6, v případě hodnoty 1, pokud je hodnota v příznaku 0 použije se bezstavová konfigurace. Pokud se má použít DHCPv6, tak se hodnota v dalším příznaku ignoruje. Další příznak je O (other stateful configuration). Other stateful configuration (stavová konfigurace ostatních parametrů) oznamuje, že pro nastavení některých parametrů se použije bezstavová konfigurace, např. pro adresy, prefix, směrování. A pro jiné parametry se má použít DHCPv6 např. pro adresy lokálních DNS serverů. To vše pokud je hodnota v poli 1. Pokud je hodnota 0 tak se veškeré parametry nastavují bezstavově. Příznak H značí home agent (domácí agent). A router tímto příznakem oznamuje, že je ochoten fungovat jako home agent pro mobilní uzel. Tento příznak má smysl pouze pro mobilitu. Router lifetime (životnost implicitního směrovače). Tímto polem router oznamuje v sekundách jak dlouho je ještě ochoten fungovat jako implicitní router pro uzly připojené 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ění dosažitelnosti. Pole retrans timer (interval opakování) pro změnu určuje dobu mezi dvěma odesláními NS. Tyto pole nacházejí hlavní uplatnění v neighbor unreachability 32

38 3. ANALÝZA IPV6 KOMUNIKACE detection. Posledním polem je options (volby). V tomto poli jsou obsaženy různé volby pro nastavení ostatních parametrů konfigurace, jako jsou např. nastavení prefixu a lokálních DNS serverů. Pokud chce ovšem počítač komunikovat po připojení 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řena prefixem fe80::/10 a interface ID. [17] Prefix je pevně daný. Proto počítači stačí si vygenerovat pouze interface ID. K tomuto se využívá modifikované EUI K vytvoření interface ID pomocí modifikovaného EUI-64 postačí počítači pouze MAC adresa jeho sít ové karty, která se pomocí jednoduchého algoritmu převede. Postup ukážu na konkrétním příkladu s MAC adresou 00:5f:47:dd:b8:c9. MAC adresa se rozdělí na 2 půlky 00:5f:47 a dd:b8:c9. Mezi ně 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ě invertovat 7. bit, který je také označován jako global flag (globální příznak). 1 znamená globální jednoznačnost a 0 lokální 5. Výsledná adresa tedy vypadá takto 025f:47ff: fedd:b8c9. Celý postup je ještě zobrazen na obrázku : 5 f : 4 7: d d: b 8: c : 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čeno, ž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ě kryptograficky generovaný Interface ID, ale ten se prakticky nepoužívá. 5. Zde je vhodné upozornit na jednu věc. Podle klasického EUI-64 je při globální jednoznačnosti 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řesně naopak. 33

39 3. ANALÝZA IPV6 KOMUNIKACE hodnotu na 7. bitu na 0 6. V MAC adrese se proto vyskytují na druhém místě pouze znaky 0,1,4,5,8,9,c,d. Ty se při modifikovaném EUI-64 mění popořadě na 2,3,6,7,a,b,e,f. Proti používání EUI-64 je řada ochránců soukromí, protože je možné podle něj identifikovat konkrétní uživatelův počítač. Po vygenerování lokální adresy, musí počítač pomocí NS zjistit, zda je jediný, kdo má tento interface ID v rámci sítě. Nemělo by se stávat, aby v jedné síti sídlilo více uzlů se stejnou adresou, ale není to vyloučeno, jelikož si MAC adresu může každý změnit podle svého. Navíc někteří 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 říká detekce duplicit. 0 bits 8 bits 16 bits 24 bits 32 bits Type = 133 Code = 0 Checksum Options Reserved = 0 Obrázek 3.9: Router solicitation (RS, Výzva směrovači) Pokud detekce duplicit dopadne dobře, počká připojený uzel než router zašle RA, aby si mohl nastavit parametry, protože zatím o síti neví nic. Nebo může být počítač aktivní a vyžádat si zaslání RA. To udělá pomocí zaslání ICMP zprávy router solicitation (RS, Výzva směrovači) na adresu ff02::2, což je multicastová adresa pro routery s link-local dosahem. Formát zprávy RS je vidět na obrázku 3.9. Součá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částí je několik voleb, podle kterých si počítač nastaví parametry připojení a to bud bezstavově nebo pomocí DHCPv6. První volba je povinná a tou je linková adresa routeru (obrázek A.4). Druhou volbou můž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ěl router přidat volbu pro každý prefix používaný v dané síti. Z toho vyplývá, že se od začátku počítalo, že jedna fyzická sít, může sloužit několika logickým sítím a tudíž mít i několik prefixů. Formát této volby je vidět na obrázku A.7. Nejvýznamnější pole v této volbě jsou samozřejmě prefix a prefix length (délka prefixu). V poli prefix je uložen vlastní prefix sítě v délce 128 bitů. 6. Vyzkoušeno na vzorku přibližně 40 ethernetových a 20 wifi karet. 34

40 3. ANALÝZA IPV6 KOMUNIKACE Pole prefix length oznamuje kolik bitů z prefixu je platných. Standardně by to mělo být 64 bitů. Za prefix length následují příznaky L, A a R. Příznak L značí on-link (na lince). Tento pří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říznak nastaven na 0, uzly v síti nemohou daný prefix konfigurovat bezstavově a jsou odkázány pouze na DHCPv6. Příznak R router address (adresa směrovače) má využití pouze pro mobilitu. Pokud má tento příznak hodnotu 1, znamená to, že v poli prefix se nalézá kompletní globální adresa routeru. Místní uzly tento příznak ignorují a z pole prefix si vezmou jen tu část předepsanou polem prefix length. Domácí agenti komunikující s mobilním uzlem, využijí příznak k získání celé adresy routerů, které poté mohou použít, pokud mobilní uzel bude dynamicky vyhledávat domácí agenty. Poslední důležitá pole jsou valid lifetime (doba platnosti) a preferred lifetime (doba preferování). Valid lifetime pole určuje 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čítač by se jí měl vyhýbat a používat ji může jen k pokračování již probíhající komunikace. Po uplynutí doby v valid lifetime poli, se daná adresa stává neplatnou a počítač ji nesmí používat a měl by odstranit její přiřazení z odpovídajícího rozhraní. Poslední volby, které lze zaslat spolu s RA, jsou volby týkající se lokálních DNS serverů. Těmito 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ět na obrázku A.8. Dlouho nebylo možné získat seznam lokálních DNS serverů jinak než stavově. Ale naštěstí 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čnu volbou Recursive DNS Server. Tato volba má v poli type hodnotu 25. Pole addresses of IPv6 Recursive DNS Servers (IPv6 adresy rekurzivních DNS serverů) obsahuje seznam lokálních DNS serverů. Počet serverů v seznamu může být více. Pole lifetime oznamuje životnost pro všechny servery uvedené v seznamu. Tato volba se může v RA objevit vícekrát s různými časy životnosti pro různé servery. Počítač si adresy DNS serverů uloží lokálně a servery kterým vypršel lifetime si vyřadí. Při novém přijmutí RA si počítač aktualizuje lifetime u lokálně uložených serverů a nové servery v ohlášení si uloží. Je doporučeno, aby byl počet serverů uložených v počítači nastaven na hodnotu 3. Pokud je tento počet překročen počítač odstraní ty servery, 35

41 3. ANALÝZA IPV6 KOMUNIKACE které mají nejnižší lifetime. Volba DNS Search List má type = 31. Pracuje se s ní shodně 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řípon). Rozdíl je, že v prvním případě 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čítač neuspěje při hledání informací k danému jménu a zadané jméno nekončilo tečkou, použije tento seznam k připojování přípon v něm obsažených. Potom hledá adresu pro dané vytvořené jméno v DNS. RFC 6106 umožňuje přijímat informace o DNS jak bezstavově tak pomocí DHCPv6. Pokud jsou informace z obou typů konfigurace relevantní, tak by je měl počítač kombinovat, aby v případě problému s jedním mechanismem měl k dispozici jiný a mohl fungovat DHCPv6 DHCP (Dynamic Host Configuration Protocol) je celkem běžná záležitost i v IPv4, pomocí něj je počítač schopen získat všechny důležité údaje pro své fungování (IP adresu, masku podsítě, implicitní router i DNS server). [15] Dnešní operační systémy jsou zpravidla v základu nastaveny na provoz pomocí DHCP. V IPv6 prošel DHCP několika změnami. Hlavní jsou zrušení broadcastových adres a poté schopnost všech uzlů si nastavit local link address (např. pomocí modified EUI-64, viz kapitola 3.3.1). A přejmenoval se na DHCPv6 (Dynamic Host Configuration Protocol for IPv6). Na DHCPv6 se podílejí tři zařízení. Klient, což je stroj, který chce získat údaje pro konfiguraci, DHCP server poskytující údaje a zprostředkovatel, který zajišt uje styk mezi klientem a serverem. Server a zprostředkovatel potom bývají společně označováni jako agenti. Že se v síti používá konfigurace pomocí DHCPv6, se klient dozví pomocí RA. (V RA bude nastaven příznak M na hodnotu 1.) Každý účastník DHCPv6 musí mít vygenerovaný DUID (DHCP Unique Identifier). DUID je unikátní identifikátor, který jednoznačně identifikuje každého účastníka DHCPv6. Tento identifikátor by měl být stálý i v případě výměny sít ové karty. Navíc každé rozhraní, které se konfiguruje pomocí DHCPv6, musí mít od klienta přidělen tzv. IA (identity association, identifikační asociace). IA by také mělo být neměnné. To znamená, že každý klient je jednoznačně 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

42 3. ANALÝZA IPV6 KOMUNIKACE DHCP agenti), kterou sděluje, že shání DHCP server, který je ochoten mu přidělit adresu. Součástí výzvy je i DUID a všechny IA spolu s vygenerovanou linkovou adresou. Pokud bude zpráva doručena přímo serveru, znamená to, že server a klient jsou na jedné lince a odpověd (advertise, ohlášení serveru) zašle přímo na jeho domovskou adresu. Pokud výzva dojde zprostředkovateli, přepošle ji na servery, které má uloženy v seznamu serverů. A následně odpověd zašle zpět klientovi. V advertise je přibalena preference ukazující ochotu serveru poskytnout IP adresy danému klientovi. Klient si ze všech ohlášení, které mu dorazily, sestaví seznam DHCP serverů a vybere si ten s největší preferencí Když si klient vybral server, odešle zprávu request (žádost) stále ještě na obecnou adresu pro všechny agenty, protože o síti pořád nic neví. Součástí žádosti je i DUID serveru (dorazil v advertise), který si vybral. Ostatní servery onu žádost ignorují a server, kterému je určena zašle zpět klientovi reply (odpověd ) spolu s přidělenými adresami. Součástí reply je trochu nepochopitelně i jestli žádosti vyhověl, protože klient si ho vybral z kladných preferencí. Klient si následně pomocí detekce duplicit ověří přidělené adresy, a bud je odmítne nebo si je přidělí. Přidělené adresy nemají neomezenou platnost. Po jejím skončení musí klient požádat o prodloužení nejdříve server, který mu adresy přidělil pomocí zprávy renew (obnovení). Pokud mu daný server neodpoví, pošle zprávu rebind (převázání) na adresu všech DHCP serverů. Touto zprávou zjišt uje, zda není nějaký jiný server ochoten mu dané adresy prodloužit. Pokud klient končí na síti, měl by požádat o uvolnění (release), aby mohla být jeho adresa přidělena dalšímu zájemci. Pokud se klient vrací zpět do sítě, třeba po nečekaném restartu, zjišt uje, zda jsou jeho stávající sít ové parametry v pořádku. V tomto případě zašle na adresu všech agentů zprávu confirm (potvrzení), jejíž součásti jsou stávající parametry jeho IA. Pokud je vše v pořádku server potvrdí platnost, v opačném případě potvrzení zamítne. Server může zaslat zprávu reconfigure. V této zprávě informuje o změně sít ových parametrů a požaduje po klientovi, aby si nastavil nové parametry. Klient poté zašle zprávu renew a server mu následně odpoví. Všechny zprávy mají stejný formát. Ten je vidět na obrázku 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řiřazení odpovědí k žádostem. Pole options obsahuje všechny informace, které jsou důležité pro konfiguraci. V DHCPv6 se lze více či méně bránit proti podvržení DHCP serverů nebo změnám v DHCP zprávách. Za tímto účelem byla vytvořena volba authenication (autentizace). V případě že klient chce ověřit platnost zpráv, 37

43 3. ANALÝZA IPV6 KOMUNIKACE 0 bits 8 bits 16 bits 24 bits Type Transaction-id 32 bits Options Obrázek 3.10: Formát zpráv v DHCPv6 musí ji přibalit k úvodní výzvě spolu s metodami, které chce pro zabezpečení používat a server následně připojí k advertise autentizační informace, které se stanou součástí všech pozdějších vyměňovaných zpráv. Bohužel je pro autentizaci použita symetrická kryptografie, a klíče použité pro autentizaci jsou uloženy na straně serveru, což představuje bezpečnostní riziko při napadení serveru. V praxi není autentizace v DHCPv6 moc použitelná. Lepší je to při komunikaci mezi serverem a zprostředkovatelem, tam lze bez problému použít IPsec. V reálu to s DHCPv6 moc dobře nevypadá, důvodem jsou zaprvé identifikátory. Protože pokud je na stroji více operačních systému nebo dojde k reinstalaci, tak počítač pokaždé bude vystupovat pod jiným DUID a v případě klonování systému na více strojů se bude zase více strojů hlásit pod jedním DUID. Dalším důvodem je, že si správci řekli, že když mají k dispozici bezstavovou konfiguraci tak proč jí nepoužívat. Z těchto důvodu se moc pomocí DHCPv6 nekonfiguruje a ani se nepředpokládá, že by se to mělo v budoucnu změnit. Bezstavová konfigurace umožňuje použití zjednodušené verze DHCPv6 (bezstavové DHCP). Do nedávna to bylo dokonce potřeba, protože nešlo bezstavovou konfigurací získat adresy lokálních DNS serverů. Důvod 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ě 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ěd ), relay forward (předání) a relay reply (odpověd k předání). S tím, že relay forward a relay reply slouží ke stejnému účelu jako request a reply, akorát se používají, pokud žádost dojde zprostředkovateli. Pokud chce klient získat informace bezstavovým DHCP odešle request, jehož součástí jsou parametry, které požaduje. Server 38

44 3. ANALÝZA IPV6 KOMUNIKACE podle toho sestaví reply a odešle ji zpět klientovi. Odpadá složité vyměňování zpráv, protože klient už má většinu nejdůležitějších údajů nastavenou bezstavově. 3.4 Mobilita Mobilita je všude proklamovaná novinka v protokolu IPv6. Zvláště v dnešní době kdy má většina lidí notebook, smartphone a tito lidé jsou neustále na cestách. Ale přesto chtějí být neustále připojení k Internetu, ve vlaku si chtějí vyřídit y, atd. Fungování i v těchto případech má zajistit mobilita. Při vývoji protokolu IPv6 se s podporou mobilních zařízení počítalo již dlouho a proto je i fungování mobility celkem promyšlené. Základní myšlenkou fungování mobility je předpoklad, že každé zařízení je někde doma. Domovem se v mobilitě myslí domácí sít, kde má mobilní uzel zaregistrovanou domácí adresu. Jejím prostřednictvím by měl být stále k dispozici i v případě, že se zrovna nenachází ve své domácí síti. Při svých cestách by měl mobilní uzel dostávat tzv. dočasné adresy (care-of addresses). Mobilita zavedla další rozšiřující hlavičku, jejíž formát je vidět na obrázku Hlavička mobility se skládá z následujících polí. Payload protocol má stejnou funkci jako next header v ostatních hlavičkách. Za ní následuje header length, a za ní následuje pole MH Type. MH type určuje jaká zpráva je poslána v této hlavičce v poli message data. Dále je v hlavičce pole reserved a checksum. Tato hlavička se používá, vždy když se přenášejí zprávy pro konfiguraci mobility. Přehled hlavních zpráv je uveden na obrázku A.9. Mobilita mimo jiné využívá mechanismy v Neighbor discovery a IPsecu. 0 bits 8 bits 16 bits 24 bits 32 bits Payload protocol Header length MH type Reserved Checksum Message data Obrázek 3.11: Formát hlavičky mobilita Přesun v síti Když se mobile node (MN, mobilní uzel) vydá na cesty a připojí se k neznámé síti, musí počkat na příchozí zprávu RA, podle kterého pozná, že 39

45 3. ANALÝZA IPV6 KOMUNIKACE se nalézá v jiné síti, než je jeho domácí. Aby mohl mobilní uzel v cizí síti normálně 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ě, adresy lokálních DNS serverů a dalších parametrů. Z RA se dozví i adresy potenciálních implicitních routerů a jeden si zvolí za svůj. Jeden z nabízených prefixů si zvolí za svůj primární, aby ho mohl použít k vytvoření primární dočasné adresy, kterou zaregistruje u domácího agenta Získání domácího agenta Registrace domácího agenta (home agent, HA) začíná zjištěním adres routerů v domácí síti, kteří jsou ochotni sloužit MN jako domácí agent. Pro zjištění adres potenciálních agentů zašle MN ICMP zprávu Home Agent Address Discovery Request Message (žádost o adresy domácích agentů) do domácí sítě. Formát zprávy je vidět na obrázku Jako data nese pouze identifikátor, aby bylo možné přiřadit následující odpověd 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říchodu zprávy zjistí domácí agent, kterému zpráva došla, adresy všech potenciálních agentů spolu s preferencí poskytnout mobilnímu uzlu své služby jako domácí agent. 0 bits 8 bits 16 bits 24 bits 32 bits Type = 144 Code = 0 Checksum Identifier Reserved = 0 Obrázek 3.12: Formát zprávy Home Agent Address Discovery Request Message Tyto adresy seřadí implicitní router v domácí síti podle preference a vytvoří z nich seznam adres v ICMP zprávě Home Agent Address Discovery Reply Message, obrázek Router následně zašle mobilnímu uzlu na jeho primární adresu tento seznam, ze kterého by si měl 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ět na obrázku Binding update se skládá z následujících polí. Sequence# (pořadové číslo), lifetime (životnost) a čtveřice příznaků tvoří základ zprávy binding update. Za nimi následuje pole pro volby. Sequence# určuje kolikátá je to zpráva binding 40

46 3. ANALÝZA IPV6 KOMUNIKACE 0 bits 8 bits 16 bits 24 bits 32 bits Type = 145 Code = 0 Checksum Identifier Reserved = 0 Home Agent Addresses Obrázek 3.13: Formát zprávy Home Agent Address Discovery Reply Message 0 bits 8 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čuje platnost dočasné adresy. Čtveřice příznaků je A, H, L, K. Příznak A (acknowledge) oznamuje, že odesílající uzel si žádá zaslání odpovědi na binding update v podobě zprávy binding acknowledgement (potvrzení vazby). V tuto dobu je nejdůležitější příznak H (home registration), který lze použít pouze při zaslání této zprávy routeru v domácí síti a znamená, že po něm žádá, aby se stal jeho HA. Třetí je příznak L, pomocí kterého uzel oznamuje HA, aby se staral i o jeho lokální adresu. Tento příznak lze použít pouze tehdy, pokud má jeho domácí adresa stejné interface ID jako jeho lokální. Poslední příznak K oznamuje domácímu agentovi, že mobilní uzel podporuje protokol IKEv2 v IPsecu. Do pole options je možné přidat doplňující volby. V tuto chvíli mobilní uzel vytvoří 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řes HA skrze právě vytvořený ESP tunel. [4] Včetně komunikace pouze mezi HA a MN. MN nastaví povinně příznak H na hodnotu 1 a odešle zprávu tunelem zpět přímo na adresu zvoleného HA. Pokud je vše v pořádku tak domácí agent zkontroluje pomocí detekce 7. Nebudu zde popisovat jak se ustavuje ESP tunel, ale mohu pro tuto problematiku doporučit bakalářskou práci zabývající se IPsecem. K dispozici zde: /fi_b/ 41

47 3. ANALÝZA IPV6 KOMUNIKACE duplicit (odešle NS na domácí adresu MN) Pokud mu nepřijde žádná odpověd, znamená to, že domácí adresu uzlu nikdo jiný nepoužívá. Dále si HA uloží dočasnou adresu do datových struktur. Zašle MN kladnou zprávu binding acknowledgement, obrázek Kladná odpověd se určuje podle pole status (stav), pokud obsahuje hodnotu 0. Od této chvíle funguje pro mobilní uzel jako domácí agent. Ještě zbývá nechat na sebe přesměrovat komunikaci v lokální síti. Zašle proto po síti několik 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čené MN odesílat na adresu HA. To samé by udělal i s lokální adresou MN pokud by byl nastaven příznak L na 1. 0 bits 8 bits 16 bits 24 bits 32 bits Status K Reserved = 0 Sequence # Lifetime Mobility options Obrázek 3.15: Formát zprávy Binding acknowledgement (Potvrzení vazby) Optimalizace cesty Pokud se objeví počítač, který chce s mobilním uzlem komunikovat, ale neví o tom, že se uzel nenalézá v domácí síti, tak nic neřeší a data odešle klasicky na domácí adresu mobilního uzlu. Domácí agent tyto data přijme, zabalí je do nového datagramu a tunelem je přepošle mobilnímu uzlu. Ten v tuto chvíli ví, že korespondent (počítač, se kterým komunikuje) netuší o jeho mobilitě. Ted by klidně mohl mobilní uzel odpovědět stylem, že si nepřeje, aby korespondent věděl, že se nalézá mimo domácí sít. A odpověd by zaslal domácímu agentovi, který by ji dále přeposlal korespondentovi. Takhle by mohly oba uzly vesele komunikovat dál. Ovšem to by znamenalo zbytečnou zátěž pro sít a domácího agenta. Právě v tuto chvíli přichází na řadu optimalizace cesty. Proto místo, aby mobilní uzel poslal odpověd korespondentovi přes HA, bude ho informovat o jeho novém umístění. Samozřejmě je nutné, aby se vůči korespondentovi prokázal, že je skutečně tím, za koho se vydává. Zašle dva na sobě nezávislé datagramy home test init (HoTI, záhajení testu domácí adresy) a care-of test init (CoTI, zahájení testu dočasné adresy). Tyto zprávy jsou přenášeny v hlavičce mobility v poli message data. HoTI zašle přes 42

48 3. ANALÝZA IPV6 KOMUNIKACE tunel domácímu agentovi, který jej přepošle korespondentovi. A CoTI zašle korespondentovi přímo. Formát zpráv je podobný a je vidět na obrázku Jedinou informaci ve zprávách je hodnota cookie, která je pro obě hlavičky náhodně 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ě zprávy vytvořením nových hodnot tokenů pro každou test init zprávu. [5] Pro HoTI vytvoří home keygen token a pro CoTI care-of keygen token. Pro vypočítání tokenů použije korespondent svůj interní klíč (Kcn), hodnoty nonce, které si generuje v několikaminutových intervalech. Jelikož HoTI a CoTI cestují jinudy, může se stát, že hodnoty budou rozdílné. Dále obě adresy mobilního uzlu (tedy jak dočasnou tak domácí) a přidá k nim ještě hodnotu 0 pro home keygen token a 1 pro care-of keygen token. A vše to předhodí hashovací funkci HMAC_SHA1. Vzorec pro výpočet tokenů 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čí zřetězení. Z tohoto výsledku se vezme prvních 64 bitů, které tvoří jednotlivé tokeny. Korespondent následně vytvoří odpovědi na HoTI a CoTI. Do těchto odpovědí vloží hodnotu nonce, použité cookie a tokeny. Tyto odpovědi jsou pojmenovány home test (HoT, test domácí adresy) a care-of test (CoT, test dočasné adresy). Formát zpráv je vidět na obrázku HoT odešle na domácí adresu MN a CoT na dočasnou adresu MN. Když dorazí HoT a CoT zprávy, vytvoří mobilní uzel pomocí tokenů klíč (Kbm) pro binding update podle následujícího vzorce: 43

49 3. ANALÝZA IPV6 KOMUNIKACE 0 bits 8 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ěj, dočasné adresy a adresy korespondenta, spočítá obdobně authenticator (autentizační hodnotu), která bude součástí volby binding authorization data (autorizační data 8 ) v binding update. Dále přidá 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římo na adresu korespondenta. Ten si ve své paměti najde hodnoty nonce podle zaslaných indexů. A stejným způsobem provede znovu výpočet autentizačních dat. Výsledek porovná s tím, co mu dorazilo. Pokud se hodnoty shodují, ví, že jedná skutečně s tím, komu poslal původní data Přenos dat Poté co se trochu složitě zajistí, že korespondent může komunikovat přímo s MH, už skoro nic nebrání jednoduchému zasílání dat. Začal bych s posláním dat od korespondenta. Každý uzel by si měl udržovat cache vazeb. V něm se nachází seznam MN, se kterými korespondent komunikuje. Cache vazeb by měla obsahovat domácí adresu MN, podle které se v cache vyhledává, odpovídající dočasnou adresu, dobu životnosti dočasné adresy ze zprávy binding update (po jejímž uplynutí se stává dočasná adresa neplatnou a musí být odstraněna), dále příznak zda pro mobilní uzel nevykonává funkci HA (to platí jen pro routery) a současnou nejvyšší hodnotu ze sequence# z binding update. 8. Nejedná se o překlep, ale skutečně se autentizační hodnota přenáší v autorizační volbě, i když autorizace a autentizace jsou dva odlišné termíny 44

50 3. ANALÝZA IPV6 KOMUNIKACE Pokaždé, když chce korespondent poslat nějaká data, měl by se kouknout do cache vazeb, zdali se v ní nevyskytuje záznam k adrese, kam chce data poslat. Pokud záznam existuje, přidá do datagramu hlavičku směrování typu 2 a odešle data na dočasnou adresu MN. Do hlavičky směrování přidá jedinou adresu a to domácí adresu MN. Hlavička směrování typu 2 vychází z klasické hlavičky směrování typu 0. Ale obsahuje pouze jedinou adresu a to domácí adresu MN. Tento typ hlavičky byl definován přímo pro mobilitu. Její formát je vidět na obrázku Když data dorazí k mobilnímu uzlu, zpracuje hlavičku směrování standardním způsobem a odešle data na domácí adresu. 0 bits 8 bits 16 bits 24 bits 32 bits Next header Header length = 2 Routing type = 2 Segments left = 1 Reserved = 0 Home Address Obrázek 3.18: Hlavička směrování typu 2 Pokud bude data odesílat mobilní uzel, přidá povinně hlavičku Destination options, ve které uvede svou domácí adresu. Korespondent musí následně 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ě nedovědí a vše bude mít stále ve své režii sít ová vrstva Návrat domů Když se mobilní uzel vrátí zpět do své domácí sítě, nemá zatím ponětí, že je zpět. To že se mobilní uzel ocitl ve své domovské síti, se dozví stejně 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ěl uloženou dočasnou adresu mobilního uzlu. U domácího agenta je nutné nastavit příznak H na hodnotu 1. Ostatním uzlům, které má také v cache vazeb zašle rovněž stejnou zprávu binding update, ovšem už bez nastaveného příznaku H. Na závěr se mobilní uzel musí chopit všech svých závazků a odešle po síti několik NA, čímž vyruší neighbor advertisement rozeslané ted už bývalým domácím agentem. 45

51 3. ANALÝZA IPV6 KOMUNIKACE 3.5 Bezpečnost IPv6 Bezpečnost v IPv6 je zajištěna pomocí IPsecu. IPsec je rozšíření IP protokolu zajišt ující jeho bezpečnost a bezpečnost protokolům na vyšších vrstvách. Základem IPsecu jsou dvě hlavičky Authentication header (AH) obrázek 3.19 a ESP header obrázek Authentication header zajišt uje ověření pravosti datagramu především adres v něm obsažených a obsahu. ESP zajišt uje kromě funkcí obsažených v AH navíc zašifrování obsahu. Protože ESP nabízí více funkcí, jak zabezpečit data, začíná se od AH ustupovat a používá se převážně jen ESP. Předpokládá se, že se v budoucnu přestane kompletně používat AH a zůstane se jen u ESP. 0 bits 8 bits 16 bits 24 bits 32 bits Next header Payload length 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čky IPsecu fungují ve dvou režimech, v tunelovacím a transportním. Transportní režim funguje způsobem, že hlavička IPsecu je přidána do datagramu a takto odeslána. Tunelovací režim obalí celý stávající datagram 46

52 3. ANALÝZA IPV6 KOMUNIKACE do nového datagramu včetně přidání nových hlaviček včetně těch z IPsecu [21]. Tunelovací režim poskytuje tedy větší úroveň zabezpečení než transportní režim, protože ten odesílá část původního datagramu v nezašifrované podobě. Útočník sice nezíská žádná data, ale bude mít přístup k adresám v datagramu a bude moci analyzovat charakter jejich komunikace. Před použitím IPsecu je nutné, aby obě strany komunikace sdílely potřebné informace jako např. konkrétní šifrovací a hashovací algoritmy, hodnoty klíčů, čítače, dobu životnosti a další. Všechny tyto hodnoty tvoří security association (SA, bezpečnostní asociaci). SA je nutné při navazování komunikace, protože SA spravuje parametry pro použití IPsecu s kterými musí obě strany souhlasit, aby mohla komunikace probíhat v zabezpečené podobě. IPsec se nepoužívá pouze při komunikaci mezi dvěma koncovými uzly, ale dá se použít i v DHCPv6 na výměnu zpráv mezi zprostředkovateli a DHCP serverem. Bohužel nejde IPsec použít pro komunikaci mezi agenty (označení pro DHCP server a zprostředkovatele) a klientem v DHCPv6. Tam se používá HMAC protokol a MD5 a vše je postaveno na symetrické kryptografii. Další případ, kdy se používá IPsec, respektive pouze ESP tunelovací režim, je v případě mobility. V mobilitě přes ESP tunel probíhá komunikace mezi domácím agentem a mobilním uzlem. Neighbor discovery umožňuje také pracovat v bezpečném režimu tzv. SEND (SEcure Neighbor Disvovery). Původní návrh SENDu počítal také s využitím IPsecu, ale protože při něm dochází k velké režii, byl tento způsob zavrhnut. Nyní se pro SEND používají Cryptographically Generated Addresses (CGA, Kryptograficky generované adresy). 47

53 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četně jejich ovládání. Popisuji zde také důvody vzniku těchto animací, spolu se srovnáním s dosud vytvořenými animacemi na podobné téma. Dále zde zmiňuji nástroj Adobe Flash Professional CS5, ve kterém jsem tyto animace vytvářel, zároveň s krátkým popisem tohoto programu. 4.1 Důvody pro animaci Přestože je IPv6 v poslední době hodně probírané téma, překvapilo mě, že se nikde na Internetu nenachází žádné animace popisující mechanismy v IPv6. Je sice možné najít na Internetu články zabývající se právě IPv6 nebo tištěné publikace, ale nikde nelze najít žádné ucelené animace, které by ukázaly, jak fungují mechanismy IPv6 1. Jediné animace zabývající se IPv6 jsou bud prezentace vytvořené v programu Microsoft PowerPoint nebo videa obsahující akorát popis IPv6. Podařilo se mi sice najít jednu animaci se jménem What is IPv6 2, ale ta bohužel popisuje jen vlastnosti IPv6. Což jsem nepovažoval jako relevantní zdroj a rozhodl jsem se vytvořit výukové animace, kde je názorně předvedeno, jak mechanismy v IPv6 fungují. A to stylem snadným pro pochopení studentům zabývajících se sítěmi i lidem kteří toho o sítích tolik neví. I když na fakultě existuje řada předmětů, ve kterých se IPv6 probírá, stále existuje spousta studentů, kteří na konci kurzu nepochopí, jak fungují jednotlivé mechanismy protokolu IPv6. Což byl další důvod pro jejich vytvoření. 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ě na vytváření interaktivních webových prezentací, animací a her. Jedním z důvodů, proč byl pro tvorbu výukových animací zvolen právě tento nástroj, je relativně snadná práce v samotném programu, jehož prostředí je rozděleno do několika částí. Největší 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řeci jen existují, ty vytvořil minulý rok jiný student z fakulty a zabývají se IPsecem 2. what-is-ipv6 48

54 4. VÝUKOVÉ ANIMACE PROTOKOLU IPV6 plocha je tou nejdůležitější částí v programu. Druhou část zabírá časová osa, která usnadňuje tvorbu animací a na které jsou všechny prvky použité v animacích přehledně rozmístěné ve vrstvách. Zároveň časová osa určuje, jak dlouho bude výsledná animace trvat a je na ní zobrazeno, v jaké části projekce se ten který objekt nachází a jak dlouho bude trvat jeho animovaný pohyb. Poslední část v programu tvoří různé nástroje a funkce, které se dají při vytváření projektů využít. Ne vše lze v programu Adobe Flash udělat jen pomocí umístění objektů, někdy je nutné něco naprogramovat. K tomu se používá scriptovací jazyk Actionscript, vyvíjený firmou Adobe. Pomocí něj je možné nechat vykonat objekty složitější funkce. Kromě toho má Flash velmi dobrou podporu ve většině operačních systémů a internetových prohlížečů a jeho neustálý vývoj znamená, že vývojáři přidávají stále nové funkce, a vylepšují podporu napříč hardwarem a softwarem 3. Právě tato podpora byla dalším důvodem výběru programu Adobe Flash pro praktickou část práce, jelikož se výsledné animace umístí na web, kde k nim budou mít uživatelé volný pří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řehrávání), fast play (rychlé přehrávání vpřed), fast back-play (rychlé přehrávání zpět). Dále jsou to funkce pro skoky v animacích. jump back a jump forward (skok zpět a vpřed). Poslední funkce, kterou animace používají, je repeat, která je k dispozici až na konci animace a vrací jednotlivé animace zpět na začátek. Všechny tyto funkce lze používat pomocí kurzoru a stejně pojmenovaných tlačítek v levém dolním a horním rohu. Tlačítka byla použita s ohledem na podobnost vzhledu s přehrávači, aby bylo na první pohled zřejmé, k čemu má dané tlačítko sloužit. Zároveň je každé tlačítko opatřeno textem popisující jeho funkci. Tento text se zobrazí při najetí kurzoru nad dané tlačítko. Ovládat animace lze i pomocí klávesnice. Základní funkce play, se používá pomocí tlačítek SPACE a PAGE DOWN. Pro rychlá přehrávání se používají klávesy M a N. M slouží pro zrychlené přehrávání vpřed a klávesa N pro zpět. Funkce jump forward lze použít stiskem klávesy RIGHT ARROW. A pro ovládání funkce jump back je ř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čítko HOME. 3. Od verze 10.2 podporuje hardwarovou akceleraci přehrávání videa. 49

55 4. VÝUKOVÉ ANIMACE PROTOKOLU IPV6 Důvod, proč není na funkci menu přidělena žádná klávesa, je ten, že v menu se lze pohybovat pouze pomocí myši proto by nebylo účelné použít klávesu, pro přechod do menu, když poté by uživatel musel stejně použít myš. Vedle tlačítka menu se nachází tlačítko obsahující odkazy na relevantní stránky zabývající se danou problematikou. Šedá tlačítka v menu přesměrovávají na animace konkrétních mechanismů. Dále se v menu nalézá ještě jedno tlačítko. Toto tlačítko s otazníkem slouží k zobrazení nápovědy, kde je shrnuto ovládání animací. Pro pohyb v některých animacích slouží i časová osa umístěná dole. Ta znázorňuje, v jakém úseku animace se uživatel právě nachází, a šedé šipky se dají použít pro přechod na začátek dílčích bloků animace. Takové ovládání animací bylo použito s ohledem na jeho přehlednost a intuitivnost. Zároveň bylo navrženo tak, aby šlo používat i s prezentérem používaným vyučujícími na fakultě informatiky. Z toho důvodu mají některé funkce více možností ovládání přes klávesnici (PAGE UP a PAGE DOWN), nebot tyto prezentéry simulují právě jejich stisk. 4.4 Vytvořené animace Zde bych rád popsal jednotlivé animace. První animace je datagrams. V této animaci je zobrazeno, jak probíhá zřetězení hlaviček protokolu IPv6. Protokol IPv6 se snažil zjednodušit hlavičky zavedením rozšiřujících hlaviček. Tím bylo zajištěno, že se použijí pouze hlavičky, které jsou relevantní. IPv4 totiž umist oval skoro všechny informace do základní hlavičky včetně funkcí, které se nemusely při přenosu datagramu použít, například fragmentace. Tato animace má jiný styl ovládání než ostatní animace. V této animaci slouží šedá tlačítka na pravé straně k výběru hlaviček použitých k zřetězení. Aktuální zřetězení je poté zobrazeno dole pomocí čtvercových tlačítek. Pomocí nich lze vybírat jaká hlavička má být zobrazena. Pole v hlavičkách obsahují další doplňkové informace, které se zobrazují při najetí nad ně. Další animace se zabývají typy adresování (unicast, multicast a anycast). V těchto animacích je vidět jakým stylem probíhá komunikace pomocí jednotlivých typů. 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ě nachází radio-buttony. Pomocí nich lze nastavit druh multicastu, který se následně projeví na změně group identifier. Pohyb v těchto animacích je řešen hlavně pomocí tlačítek a kláves RIGHT 50

56 4. VÝUKOVÉ ANIMACE PROTOKOLU IPV6 a LEFT ARROW. Následně je možné mezi touto skupinou animací přecházet pomocí tlačítek umístěných na pravé straně. Ve třetí skupině jsem se zabýval fungováním protokolu neighbor discovery. Přesněji Zjišt ování linkových adres a Detekci dosažitelnosti souseda. V těchto animacích je názorně ukázán formát zpráv používaných v neighbor discovery a jakým způsoben probíhá komunikace mezi účastníky. Ovládání v těchto animacích je standardní, jak bylo popsáno v předchozí kapitole. Za zmínku stojí ještě animace neighbor unreachability detection, kde při najetí myší nad jednotlivé stavy se zobrazí popis stavu a co mu předchází, respektive následuje po něm. Čtvrtá část popisuje fungování bezstavové autokonfigurace. Na začátku animace je zobrazeno, jak si uzel vygeneruje lokální adresu. Dále je v animaci zobrazeno, jakým způsobem dochází k výměně zpráv nutných pro správné konfigurování připojení včetně jejich formátu a použitých voleb. Tato animace se ovládá standardním způsobem. Poslední animace je Mobilita. Tato animace názorně předvádí, jak probíhá získání domácího agenta, optimalizaci cesty pro komunikaci s uzlem, který je připojen někde v Internetu. Dále je v animaci vidět jak probíhá komunikace po optimalizaci cesty a návrat mobilního uzlu zpět do domácí sítě. Také tato animace obsahuje klasické ovládání popsané dříve. V menu je ještě uveden odkaz na animace IPsec, které vytvořil jiný student. Nicméně dohodl jsem se, že by bylo vhodně mít je zde uvedeny, jelikož se také zabývají mechanismem IPv6. 51

57 5 Závěr Cílem práce bylo vytvořit výukové animace vybraných mechanismů používaných v protokolu IPv6, které měly vhodným způsobem prezentovat, jak dané mechanismy pracují. V písemné práci jsem je měl podrobně popsat. Animace vytvořené pro praktickou část najdou využití hlavně ve výuce sít ových předmětů na fakultě informatiky, které mají součástí osnovy i protokol IPv6. Výsledné animace jsem předložil několika studentům z fakulty, aby se mi k nim později vyjádřili a sdělili mi své dojmy. Zejména jestli byli schopni pochopit, jak dané mechanismy fungují, zda jim přijde ovládání intuitivní a také, jaký mají z animací celkový dojem. Vzorek studentů obsahoval, jak studenty kteří prošli větším množstvím sít ových předmětů, tak i těch, kteří mají za sebou jen základní předmět týkající se sítí. Na základě těchto podnětů získaly animace současnou podobu. Osobně věřím, že tyto animace budou používat i uživatelé, kteří nejsou z fakulty informatiky. Textová část práce má sloužit jako doplňkový a rozšiřující materiál k vytvořeným animacím. V této části jsem se snažil o detailní popis fungování vybraných mechanismů, doplněné pro názornost formáty zpráv, použitých pro výměnu informací. Jelikož mechanismy obsahují větší množství informací, které nemohou být opomenuty, je rozsah textové části větší než je u bakalářských prací obvyklé. Tato práce mi ukázala, že má smysl vytvořit i animace na další mechanismy IPv6, nebot studentům je názorně a nenásilnou cestou předvedeno, jak dané mechanismy fungují. Ve výsledku to může znamenat, že si z animací zapamatují více, než kdyby četli jen holý text. Dále tato práce nabízí možnost budoucího rozšíření o další animace v podobném duchu jako s IPsecem. Kdy je možné tyto animace provázat, případně jim dát v budoucnu jednotnou podobu. 52

58 Literatura [1] 6DEPLOY. IPv6 Autoconfiguration [online]. [cit. 27. března 2012]. Dostupné z: < deploy_ipv6_autoconfiguration_mechs_ _ v2_0.pdf> [2] ABLEY, J., NEVILLE-NEIL, G., SAVOLA, P. Deprecation of Type 0 Routing Headers in IPv6. [online]. prosinec [cit. 13. března 2012]. Dostupné z: < [3] Adobe Creative Team. Adobe Flash CS5 Professional, Oficiální výukový kurz. 1. vyd. Brno: COMPUTER PRESS, s.: ISBN: [cit. 13. května 2012]. [4] ARKKO, Jari, DEVARAPALLI, Vijay, DUPONT, Francis. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. [online]. červen 2004 [cit. 9. května 2012]. Dostupné z: < ietf.org/html/rfc3776> [5] ARKKO, Jari, JOHNSON, David B., PERKINS, Charles E. Mobility Support in IPv6. [online]. červenec 2011 [cit. 9. května 2012]. Dostupné z: < [6] BÉLAI, I. Referenčný model komunikácie ISO/OSI [online] [cit. 21. listopadu 2011]. Slovenská technická univerzita v Bratislavě, Fakulta elektrotechniky a informatiky. Dostupné z: < stuba.sk/pkom/html/download/kapitola_2.pdf> [7] BIONDI, Philippe, EBALARD, Arnaud. IPv6 Routing Header Security s. 57. [online] [cit. 13. března 2012]. Dostupné z: < secdev.org/conf/ipv6_rh_security-csw07.pdf> [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: <http: //tools.ietf.org/html/rfc3306> [10] HABERMAN, Brian, SAVOLA, Pekka. Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. [online]. listopad

59 5. ZÁVĚR [cit. 5. ledna 2012]. Dostupné z: < rfc3956> [11] HABERMAN, Brian, HINDEN, Robert M. Unique Local IPv6 Unicast Addresses. [online]. říjen 2005 [cit. 2. ledna 2012]. Dostupné z: <http: //tools.ietf.org/html/rfc4193> [12] HAGEN, Silvia. IPv6 essentials. 2nd ed. Beijing: O Reilly, 2006, 418 s. ISBN [cit. 15. září 2011] [13] HUSTON, Geoff. IPv6 s. 35. [online] [cit. 12. března 2012]. Dostupné z: < ipv6.pdf> [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. říjen 2006 [cit. 22. března 2012]. Dostupné z: < dhcpv6.pdf> [16] NARTEN Thomas, NORDMARK, Erik, SIMPSON, William Allen, SOLIMAN, Hesman. Neighbor Discovery for IP version 6 (IPv6). [online]. září 2007 [cit. 25. března 2012]. Dostupné z: < org/html/rfc4861> [17] NARTEN Thomas, THOMSON, Susan, JINMEI, Tatuya. IPv6 Stateless Address Autoconfiguration. [online]. září 2007 [cit. 27. března 2012]. Dostupné z: < [18] PETERKA, Jiří. Referenční model ISO/OSI [online] [cit. 21. listopadu 2011]. Dostupné z: < ai1552.php3> [19] PETERKA, Jiří. Sít ová vrstva [cit. 11. prosince 2011]. Dostupné z: < [20] PUŽMANOVÁ, Rita. TCP/IP v kostce. 2. upr. a rozš. vyd. České Budějovice: Kopp, 2009, 619 s. ISBN s. 52. [cit. 21. listopadu 2011]. [21] RACEK, Lukáš. Výuková animace bezpečnostních mechanismů IPv6 protokolu [online] [cit. 10. května 2012]. Bakalářská práce. Masarykova 54

60 5. ZÁVĚR 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, s.: ISBN: s [cit. 1. dubna 2012]. Dostupné z: < edice/pavel_satrapa_ipv6_2011.pdf> [23] SATRAPA, Pavel. IPv6: internetový protokol verze 6. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, s.: ISBN: obr. 3.15, s. 82. [cit. 30. března 2012]. Dostupné z: < files/nic/edice/pavel_satrapa_ipv6_2011.pdf> [24] Wikipedie: Otevřená encyklopedie: Relační vrstva [online] [cit. 21. listopadu 2011]. Dostupné z: < Relaèní_vrstva> 55

61 A Obrázky 0 Hop by Hop options header 43 Routing header 44 Fragment header 50 ESP header 51 Authentication header 60 Destination options header 135 Mobility header 6 TCP 17 UDP 58 ICMP Obrázek A.1: Hlavičky a jejich hodnoty 0 Reserved (Rezervováno) 1 Interface-Local (Rozhraní) 2 Link-Local (Linka) 3 Reserved (Rezervováno) 4 Admin-Local (správa) 5 Site-Local (Místo) 6, 7 Unassigned (Nepřiřazeno) 8 Organization-Local (Organizace) 9-d Unassigned (Nepřiřazeno) e Global (Globální) f Reserved (Rezervováno) Obrázek A.2: Dosahy 56

62 A. OBRÁZKY Obrázek A.3: Dosah v praxi [23] 0 bits 8 bits 16 bits 24 bits Type = 1 Length Source link-layer address 32 bits Obrázek A.4: Volba Source link options Internet _ address _ Physical _ address _ Type fe80::1 00:00:00:00:00:00 Reachable fe80::2 11:22:33:44:55:66 Stale Obrázek A.5: Cache sousedů 57